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Abstract 


This  bibliography  is  an  outgrowth  of  a  graduate  course  on 
Computer  Program  Engineering  and  is  an  attempt  to  provide  some 
guidance  to  the  literature  in  this  area.  References  annotated  by 
students  in  the  course  are  provided,  along  with  a  cross  reference 
list  by  topic  area.  This  report  updates  and  supersedes  CSRG-69. 
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Preface 


Computer  program  engineering  is  a  discipline  directed  to  the 
production  of  computer  programs  that  are  correct,  efficient, 
flexible,  maintainable,  and  understandable;  in  reasonable  time 
spans,  at  acceptable  costs. 

--  J.J.  Horning 


This  bibliography  is  an  outgrowth  of  a  graduate  course  on 
computer  program  engineering  (CS2105)  taught  in  1971  by  W.M. 
McKeeman,  in  1975  by  D. B.  Wortman  and  in  1972-1974,  1976  by  J.J. 
Horning.  Students  in  the  course  were  required  to  read  and 
annotate  articles  that  they  judged  appropriate  for  inclusion  in 
the  bibliography,  and  to  indicate  articles  in  previous  editions 
that  should  be  deleted.  These  submissions  were  editei  and 
augmented  by  the  current  editor  and  his  predecessors,  J.D.  Gannon, 
J.V.  Guttag,  and  D.H.  Thompson. 

The  bibliography  is  now  divided  into  three  main  parts.  Part  1 
contains  lists  of  references  to  annotated  articles  in  Parts  2  and 
3.  Part  2  is  divided  into  eight  sections  corresponding  to  major 
topic  areas.  A  finer  subdivision  within  each  section  gives  lists 
of  entries  relevant  to  specialized  topics.  At  the  beginning  of 
each  section  is  a  short  list  of  references  deemed  to  be  of  special 
interest. 

Parts  2  and  3  contain  the  references  and  annotations.  Within 
each  part,  the  entries  are  ordered  alphabetically  by  author  and 
year.  Where  possible.  Computing  Reviews  review  numbers  are  also 
cited  in  the  heading  of  entries.  The  division  of  the  annotations 
into  two  parts  is  an  attempt  to  reflect  the  rapidly  changing 
nature  of  computer  program  engineering.  All  relatively  recent 
articles  are  in  Part  2.  Articles  older  than  six  years  (1971  or 
before)  are  placed  in  Part  3. 

Corrections,  new  entries,  and  annotations  are  encouraged  from 
all  interested  parties. 
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Part  1 


Topic  Areas 


I .  General 


Bauer72f  Bauer73,  Bauer76,  Brooks75,  Brown74,  Brown75f 
Buxton70,  Buxton71r  Dijkstra75a#  Dijkstra76,  Fosdick72r 
Jardine75,  Miller74,  Naur69b,  Riddle72,  Steele75,  Turski70, 
VanTassel74r  Weinberg71r  Weinberg72,  Yourdon75 

Highly  recommended: 

Brooks75,  Buxton70,  Dijkstra76,  Naur69b 


I I .  Management 


Arvey73,  Baker72a,  Baker72b,  Baker73,  Boehm73r 
Brooks75,  Brophy70,  Brown74#  Buxton70,  Cole73, 
Evans70r  Griffith72  ,  Gunderman73,  Halstead73# 
Maynard72,  Mills71,  Mills71a,  Mills73b#  Myers73 
Parnas72cc,  Rochkind75,  Schwartz75,  Simmons72, 
Thorpe76#  Wadsworth73,  Wolverton74 


Bratman7  5 , 
Conw  ay68  , 
Haney7  2 , 
,  Naur69b, 
Smit  h72a. 


Highly  recommended: 


Baker72b#  Mills71a 


Cost  estimation: 

Boehm73,  Buxton70,  Evans70,  Halstead73,  Haney72,  Maynard72r 
Naur69b,  Royce75,  Smith72af  Wclverton74,  Wolverton75 

Project  scheduling: 

Brooks75,  Evans70,  Haney72,  Naur69b,  Smith72a 
Personnel: 

Arvey73,  Brooks75,  Brown74r  Buxton70,  Griffith72,  Gunderman73, 
Maynard72,  Naur69b,  Scott75,  Wadsworth73 

Organization  of  personnel: 

Baker72a,  Brophy70,  Cole73,  Conway68,  Mills71,  Mills73b, 
Myers73,  Naur69b,  Parnas72c,  Simmons72#  Smith72a,  Thorpe76 
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Chief  programmer  teams: 

Baker72a,  Baker72bff  Baker73,  Inmon76,  Mills71a,  Thorpe76 


III.  Design 


Baker 72c , 
Boehm75a» 


Balzer67r  Bard72,  Bauer72#  Belady71,  Bochmann73b 
Boehm75br  Brinch  Hansen7Qr  Brinch  Hansen73a 


Brinch  Hansen73b,  Brooks75,  Brophy70,  Brown71,  Buxton70 
Cohen  72,  Cole73,  Conway63,  Corbato72,  Cox71,  Dakin73,  Denil73 
DeRemer75,  Dijkstra65a,  Dijkstra68b,  Evans70,  Fient73 
Fosdick72,  Graham73a,  Gries71,  Gunderman73,  Guttag75 
Habermann73,  Hague76,  Halstead72,  Halstead73,  Haney72 
Hoare72a,  Holt73b,  Holt75r  Horning74a,  Inmon76,  Jones76 
Knuth71b,  Kulsrud74,  Lampson71,  Iassettre72,  Liskov72 
Lucas73,  Madnick70,  Margolin72,  Maynard72,  McFarland70 
McKeeman67,  McKeeman7Q,  McKeeman72,  Mills73a,  Morris73b 
Morris73d,  Mosedale73 ,  Myers73,  Naur69b,  Neumann69,  Ogdin73 
Organick72,  Parnas67,  Parnas71,  Parnas72b,  Parnas72c 
Parnas72d,  Parnas72e,  Parnas75,  Parnas76b,  Pearson73 
Randell72,  Ross67,  Ross7Q,  Royce75,  Satterthwaite72 ,  Shaw72 
S hneiderman76,  Smith72a,  Steel67,  Stevens74,  Tou71,  Tsui76 
Waite70,  Warren75,  Weiderman71„  Weller73,  Wells73,  Wheel er72 
Wirth71c,  Wolverton75,  Woodger72,  Wortman72,  Yohe74 


Highly  recommended: 

Belady71,  Dijkstra68b,  Parnas72e 
Machine  design: 

McFarland7Q,  McKeeman67,  Tou71,  Wortman72 
Compiler  design: 


Conway63,  Gries71,  Holt 73br  Horning74a,  Knuth71b,  Kulsrud74, 
Lucas73,  Satterth waite72,  Wells73,  Wirth71c 


Operating  system  design: 

Bard72,  Brinch  Hansen70,  Brinch  Hansen73a,  Brinch  Hansen73b, 
Brooks75,  Buxton70,  Corbato72,  Cox7  1 ,  Bijkstra68b,  Holt75, 
Lassettre72,  Margolin72,  Naur69b,  0rganick72,  Randell72 

Design  methodologies: 

Bauer72*  Bochmann73b ,  Boehm75a,  Brinch  Hansen70, 
Brinch  Hansen73a,  Brinch  Hansen73b,  Buxton70,  Cole73, 
Conway63,  Dakin73,  Denil73,  Dijkstra65a,  Dijkstra68bf 
Graham71,  Graham73a,  Habermann73,  Horning74a,  Inmon76, 
Jones76,  Liskov72,  Morris73b,  Naur69b,  Neumann69,  Parnas67r 
Parnas71,  Parnas72c,  Parnas72d,  Parnas72e,  Ross67,  Shaw72, 
Shneiderman76,  Weiderman71,  Woodger72,  Yohe74 
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Specif icat ions: 

Guttag75,  Noonan75,  Ogdin73,  Parnas71,  Parnas72b,  Parnas72e 
S  ch  wart z75 

Modularity: 

Baker72c,  Bauer72,  Belady7 1 ,  Cohen72,  Conway63,  Denil73 
DeRemer75,  Dijkstra68br  Guttag75,  Haney72,  Hoare72a,  Holt75 
Liskov72,  Madnick70r  Maynard72,  McKeeman72,  Morris73d 
Mosedale73,  Myers73#  Naur69br  Ogdin73#  Organick72,  Parnas67 
Parnas71,  Parnas72b,  Parnas72c,  Parnas72d,  Pearson73 
Stevens74 

Complexity  metrics: 

Belady71,  Halstead72,  Mills73a,  Stucki75,  Wheeler72 
Integrated  simulation: 

Graham73a,  Parnas67#  Weiderman71 
Standards : 

Brophy70,  Fient73,  Fosdick72,  Naur69b#  Steel67,  Weller73 
Modifiability: 

Balzer67r  Bauer72»  Belady71,  Graham73a,  Gunderman73 
Madnick70,  Naur69b,  Ross67#  Ross70 

Portability: 

Brophy70f  Brown71r  Buxton70,  Cook76#  Cox71,  Evans70,  Hague76 
Halstead73,  Haney72r  McKeeman70#  Smith72a#  Waite70#  Warren75 


I V .  Programming 


Abrahams75,  Ashcroft72,  Baker75,  Balzer67,  Barth74,  Bauer72 
Benson73,  Bloom74,  Bloom75,  Bochmann73a,  Brinch  Hansen72a 
Brinch  Hansen72b,  Brinch  Hansen73b,  Brophy70,  Brown72 
Burstall69a,  Euxton70,  Cheatham72a,  Cheatham72b,  Clark73 
ConwaySB,  Cooke75b,  Cook76#  Corbato69,  Cunningham76 ,  Dahl72 
Dar lington76 ,  Demillo76,  Denil73,  Dennis75r  Dijkstra62 
Dijkstra65a,  Dijkstra65b,  Dijkstra68a,  Dijkstra68c 
Dijkstra68d,  Dijkstra71a,  Dijkstra71b,  Dijkstra72a 
Dijkstra72b,  Dikstra65a,  Dijkstra75b,  Ershov72,  Feldman68 
Feurman76#  Fisher72#  Floyd72,  Friend75,  Gaines69,  Gannon75a 
Gannon75b#  Gannon75c,  Gerhart76#  Gilb76,  Good70r  Gries71 
Gries74,  Griffith72,  Gu nderman73 ,  Hammer76,  Heidorn76 
Henderson72,  Henricksen72r  Hoare69,  Hoare71a,  Hoare72a 
Hoare72b,  Hoare73a,  Hoare73b,  Hoare74,  Hoare75,  Holt73a 
Holt73b,  Hopkins72,  Horning74a,  Horning76,  Horowitz75 
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Howden76,  Ichbiah73,  Kernighan74a#  Kernighan74b ,  Knuth71a, 
Knuth73a,  Knuth74,  Kosinski73#  Kulsrud74,  Leavenwort h72 , 
Ledgard75,  Linden76,  Liskov72,  Liskov73,  Liskov74,  Manna71f 
Marcotty74,  Hart in 74 ,  Matuszek  76,  McClure75,  McCracken72, 
McFarland70,  McKeeman66,  McKeeman67 ,  McKeeman70,  McKeeman74, 
McKeeman 75,  Miller74,  H ills72,  Mills73a,  Mills73b,  Mitchell76, 
Morris73b,  Morris73c,  Morris73d,  Nassi73,  Naur69a,  Naur72, 
Neely73,  Neely76,  Nie vergelt70 ,  Noonan75,  Parnas76a, 
Peterson73,  Randell75,  Richards69,  Ross70,  Ross76,  Rustin71# 
Sammet71#  Satterthwaite72r  Schneiderman73 ,  Shaw76,  Sime73, 
Snowdon72,  Snowdon73,  Standish75,  Tou71,  Ward76,  Kasser man75r 
Weinberg71f  Weinberg75,  Wells73,  Wirth68,  Wirth71a,  Wirth71b, 
Wirth73,  Wirth74,  Wirth75,  Woodger72,  Wortman72,  Wulf71a, 
W ulf 7 1 b,  Wulf72a,  Wulf72b,  »ulf72c,  Youngs70,  Zahn75, 
Zelkowitz74 


Highly  recommended: 

DahX72,  Dijkstra72a,  Dijkstra72b,  Hoare72a,  Hoare73a# 
Kernighan74a,  Liskov75,  Naur63,  Wirth71af  Wirth71br  Wulf73 

Attitudes: 


Brophy70,  Brown72,  Dijkstra62,  Dijkstra65a,  Dijkstra72a, 
Ershov72,  Gunderman73 ,  Horning74a,  Miller74 


Structured  programming: 

Abrahams75,  Baker75,  Boehm75a,  Barth74,  Bauer72,  Benson73, 
Bloom75,  Buxton70,  Cheatham72a,  Cunningham76 ,  Dahl72, 
Demillo76,  Denil73,  Dijkstra65a,  Dijkstra68d,  Dijkstra71a, 
Bljkstra71b,  Dijkstra72b,  Dijkstra76,  Feurman76,  Floyd72, 
Gilb76r  Henderson72,  Holt73a#  Holt73b,  Horowitz75, 
Kernighan74a ,  Kernigfaan74b,  Knuth73a,  Knuth74,  Liskov72, 
Liskov73,  Martin74,  McClure75,  Mills72,  Mills73a,  Mills73br 
Morris73b,  Nassi73,  Naur69a,  Naur72,  Neely76,  Noonan75, 
Ross70,  Rustin71,  Schneider man73,  Snowdon72,  Snowdon73,  Tou71, 
Wirth71a,  Wirth71b,  Wirth73,  Wirth74,  Woodger72,  Yourdon75, 
Zelko witz74 


Readability : 

Brophy70,  Darlington76 ,  Ker nigh an74b ,  McCracken72,  Mills70r 
Mills73b,  Yourdon75 

Human  factors  in  programming: 

Cooke75b,  Gannon75a,  Gannon75b,  Gannon75c,  Griffith72r 
Horning74a,  Miller74,  Sime73,  Weinberg71,  Youngs70 
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Criteria  for  language  design: 

Brinch  Hansen72a,  Buxton70#  Cheatham72ar  Dikstra65ar 

Dijkstra76,  Gannon75a,  Gannon75b#  Gannon75c,  Hoare69, 
Hoare71a,  Hoare72a,  Hoare72b,  Hoare73a,  Knuth74,  Kulsrud74, 
Liskov73#  McKeeman66,  McKeeman74,  McKeeman75,  Morris73c, 
Morris73d,  Neely73,  Ross70,  Sammet71#  Schneiderman73, 
Wasserman75r  Wells73,  Wirth71b,  Wirth75,  Wulf71a,  Wulf71b 

Data  abstractions: 

Flon76r  Guttag75,  Hammer76,  Horning76,  Linden76,  Liskov74, 
Liskov75,  Mitchell76,  Morris73d#  Parnas76a,  Ross76,  Shaw76, 
Shneiderman76 

Data  structures: 

Balzer67,  Dahl72,  Hoare72a,  Hoare72b,  Hoare73b,  Ichbiah73r 
Knuth73a,  Liskov73,  Morris73d,  Ross70,  Schneiderman73 ,  Tou71 

Control  structures: 

Barth74,  Bloom74,  Bochmann7 3a ,  Brinch  Hansen73br  Conway63, 
Dijkstra75b,  Dijkstra76,  Fisher72,  Hoare72b#  Hoare74,  Holt73a, 
Knuth73ar  Kosinski73f  Ledgard75#  Nassi73,  Nie verge lt7 0  , 
Peterson73,  Sime73r  Ward76#  Weinberg75#  Wulf72c,  Zahn75 

The  GOTO: 

Ashcroft72r  Dijkstra65ar  Dijkstra68a,  Gries74,  Hopkins72, 
Knuth71a,  Knuth74r  Lea venworth72,  Peterson73,  Rustin71, 

Sime73,  Tou71 ,  Wirth74,  Wulf72ar  Wulf72b,  Wulf72c 

Other  language  features: 

Brinch  Hansen72ar  Brinch  Hansen73b,  Dennis75,  Dijkstra65b, 

Dijkstra68c,  Gaines69r  Hoare72b,  Liskov73,  Matuszek76, 

Rustin71r  Sattert hwaite72 ,  Standish75,  Tou71 

Implementation  languages: 

Brinch  Hansen73b,  Buxton70,  Cheatham72a,  Clark73,  Corbato69, 
Henricksen72 ,  Ichbiah73,  Marcotty74,  Richards69,  Sammet71, 
Wegbreit71,  Wells73r  Wirth68,  Wirth71b#  Wulf71a,  Wulf71b 

Translator  writing  systems: 

Feldman68,  Gries71,  McKeeman70 

Parallel  programming: 

Ashcroft72,  Brinch  Hansen72a,  Brinch  Hansen72b#  Hoare72b 
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Program  construction  aids: 

Burstall69a,  Buxton70,  Cheatham72b,  Floyd72f  Friend75,  Good70 
Heidorn76„  Manna71,  Rochkind75,  Snowdon72,  Snowdon73 

Language-directed  machine  design: 

Abrams7Q,  McFarland70,  McKeeman67,  Wortman72 


V .  Correctness.  Validation,  and  Debugging 


Alberts76,  Alexander71,  Allen71,  Ashcroft71,  Basu75a,  Basu75b 
Brinch  Hansen73a,  Brooks75,  Brown73,  Burstall69a,  Burstall69b 
Burstall72,  Buxton70,  Cheatham72a,  Cheatham72b,  Clark73 

Clint72,  Clint73,  Cooke75a,  Dakin73,  Dijkstra62,  Dijkstra65a 
Dijkstra65b,  Dijkstra68c,  Dijkstra68d,  Dijkstra71a 

Dijkstra72b,  Dijkstra73,  Dijkstra75c,  Donahue75,  Elspas71 

Elspas72,  Flon76,  Floyd67,  Floyd72,  Fong73 ,  Fosdick72 
Freeman73,  Gaines69,  Gannon75,  German75,  Good70,  Good75 
Goodenough75,  Gould71,  Gould73,  Graham73b,  Gries71 

Gunderman73,  Haney72,  Henderson72,  Hetzel73,  Hoare69 

Hoare71a,  Hoare71b,  Hoare72a,  Hoare72b,  Hoare72c,  Horning74b 
King71,  King76,  Lanzarone72,  Lassettre72,  Liskov72,  Liskov73 
Loeser76,  London70a,  London70b,  London70c,  London71,  Lucas73 
Manna71,  Manna73,  Miller74,  Mills73a,  Mills73b,  Mills75 
Morris73a,  Morris73c,  Morris73d,  Naur69a,  Naur69b,  Ogdin73 
0sterweil76,  Parnas72b,  Parnas72f,  Poole73,  Prokop73,  Rain73 
Ramamoorthy75,  Randell71,  Randell72r  Rustin71 

Satterthwaite72,  Schneiderman73,  Shooman75,  Sites74,  Smith72b 
Snowdon72,  Stucki75,  Tanenbaum76,  Wulf75,  Yohe74 

Highly  recommended: 

Elspas72,  Floyd67,  Grishman70,  Hoare69,  Hoare71b,  London70c 
Satterthwaite72 

Reliability : 

Alberts76,  Buxton70,  Clark73,  Dijkstra62,  Dijkstra68d 
Dijkstra71a,  Donahue75,  Elspas71,  Gannon75a,  Gannon75b 

Gannon75c,  Hoare72a,  Horning74b,  Liskov72,  Liskov73,  Mills73b 
Morris73c,  Morris73d,  Naur69b,  Ogdin73,  Parnas72f 

Ramamoorthy75,  Randell71,  Randell72,  Schneiderman73 

Validation: 

Brooks75,  Brown73,  Buxton70,  Cheatham72a,  Cheatham72b 
Dijkstra62,  Dijkstra65a,  Dijkstra68c,  Dijkstra72b,  Elspas72 
Floyd72,  Fosdick72,  Hoare71a,  Hoare71b,  Hoare72a,  Hoare72b 
Lanzarone72,  Liskov72,  London70a,  London70b,  Mills73a 

Morris73d,  Parnas76b,  Poole73,  Prokop73,  Ramamoorthy75 
R  ustin7 1 
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Correctness  -  formal  approaches: 

Allen71,  Ashcroft71#  Basu75a,  Basu75b,  Burstall69a, 
Burstall69b,  Burstall72,  Clint72#  Clint73,  Dijkstra73, 
Dijkstra75c,  Elspas72r  Floyd67,  Floyd72#  German75,  Good70, 
Hoare69,  Hoare71a„  Hoare71b#  Hoare72a,  Hoare72b,  Hoare72c, 
King71,  Manna71r  Manna73,  Morris73a,  Rustin71,  Sites74 

Correctness  -  informal  approaches: 

Dijkstra65a,  Dijkstra65b,  Dijkstra68c,  Dijkstra68dr 

Dijkstra71a,  Dijkstra72b,  Elspas72,  Good75,  King76,  London70cr 
London71,  Mills75,  Naur69a,  Smith72b#  Snowdon72r  Wegbreit76 

Testing: 

Alexander71,  Brinch  Hansen73a,  Brooks75,  Brown73,  Buxton70, 
Haney72#  Hetzel73,  Lucas73#  Mills73b,  Osterweil76  Parnas72b, 
Poole73#  Rain73r  Tanenbaum76 

Automatic  generation  of  test  cases: 

Elspas71,  Goodenough75 

Debugging : 

Brown73,  Buxton70,  Dakin73,  Fong73r  Gaines69,  Gould73r 
Grishman70,  Gunderman73,  Henderson72,  Lassettre72,  Loeser76, 
Miller74#  Ogdin73r  Poole73#  Rain73r  Rustin71#  Satterthwai te72 , 
Yohe74,  Yourdon75 

Syntax  error  recovery: 

Graham73b,  Gries7 1 


VI.  Evaluation 


Alexander71#  Arvey73,  Eard72,  Bard73,  Buxton70,  Cheatham72b, 
Cohen74r  Dakin73,  Deutsch72#  Graham73a,  Hatfield71,  Holland73, 
Kimbleton72,  Lassettre72,  Lucas73,  Margolin72,  Miller72, 
Naur69b,  Parnas67,  Randell71 ,  Rustin71,  Scott75,  Thayer75, 
Trivedi75,  Wegbreit76,  Weiderman71,  Wortman72 


Highly  recommended: 

Parnas67 
Evaluation : 

Alexander71,  Arvey73,  Buxton70,  Cheatham72b,  Cohen74r 
Holland73#  Kimbleton72r  Lucas73,  Miller72#  Randell71, 
W  ortman72 
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Modelling  : 

Bard72,  Lassettre72,  Margolin72,  Trivedi75 
Simulation: 

Graham73a,  Parnas67,  Rustin71,  Weiderman71 
Monitoring : 

Arden69,  Bard73,  Dakin73r  Deutsch72#  Hatfield71 ,  Naur69b 


VII.  Documentation 


Auerbach72#  Belady71,  Berry75#  Brinch  Hansen73a,  Brown74 
Brophy70,  Brooks75,  Fosdick72,  Habermann73r  Maynard72 
Mills73br  Naur69b,  Parnas72e,  Pearson73,  Poole73r  Scowen71 
Simmons72,  Van  Duyn72,  Hatkins73 


VIII.  Miscellaneous 

Arden72,  Bauer73,  Buxton70,  Buxton71,  Cheat ham7 2br  Harker75 
Holt73a,  Parnas72a,  Parnas72d#  Shaw72,  Weinberg71 

Highly  recommended: 

Cheatham72b 

Education : 

Bauer73,  Buxton70,  Buxton71  r  Harker75#  Holt73a,  Parnas72a 
Parnas72d,  Weinberg71 

Laborator ies: 

Arden72,  Euxton70,  Cheatham72br  Parnas72d#  Shaw72 


Part  2 


Current  Articles 


AERAHAMS75 

Abrahams,  P.;  "Structured  Programming"  Considered  Harmful;  SIGPLAN 
Notices  10,4  (April  1975)  pp. 13-24. 

Contrary  to  what  may  be  inferred  from  the  title,  the  author  is  not 
advocating  the  abolishment  of  structured  programming.  What  he  is 
saying  is  that  the  notion  of  "structured  programming"  is  not  the 
panacea  to  problems  of  programming;  it  is  harmful  in  that  "if  it 
is  treated  as  a  collection  of  inflexible  rules  which  can  replace 
good  judgement,  it  will  ultimately  increase  rather  than  decrease 
our  effects,  while  concealing  from  us  the  fact  that  this  increase 
has  occured" .  On  the  other  hand  if  structured  programming  is 
treated  as  a  collection  of  good  programming  practices,  it  is 
immensely  helpful. 

There  are  seven  ideas  that  seem  to  be  regarded  as  aspects  of 
structured  programming:  programming  by  step-wise  refinement,  use 
of  hierarchical  levels  of  abstraction  as  a  guiding  design 
principle,  programming  without  goto,  breaking  up  programs  into 
modules  that  occupy  less  than  a  page,  avoidance  of  global 
variables,  proofs  of  program  correctness,  and  the  "chief 
programmer  team"  approach  to  the  project  organization. 

Despite  all  this,  there  is  no  agreed  definition  of  structured 
programming.  The  paper  tries  to  shoot  down  each  of  these  aspects. 
Admittedly,  this  article  is  quite  provocative  and  against 
established  convention  but  the  author*s  arguments  are  not 
dismissable  and  are  worth  thinking  about. 


A  LBERTS76 

Alberts,  D.S.;  The  Economics  of  Software  Quality  Assurance;  AFIPS 
Conference  Proceedings  45  (1976)  pp. 433-442. 

With  the  high  cost  of  software  development,  one  important  aspect 
of  computer  program  engineering  is  the  cost.  Based  on  data  from  a 
variety  of  sources  (57  references),  the  author  investigates  cost 
effectiveness  considerations  of  producing  reliable  software.  Four 
phases  of  software  production  (conceptual,  requirements, 
development,  and  operations)  are  examined  with  the  aim  of 
identifying  the  source,  type,  and  relative  cost  of  errors.  The 
most  economical  methods  of  reducing  these  errors  are  examined. 
Not  unexpectedly,  the  highest  costs  are  found  in  the  development 
and  operations  phases  of  production.  Of  three  types  of  errors 
(design,  programming/logic,  and  syntax),  design  errors  accounted 
for  more  than  80%  of  the  total  cost  of  errors. 

In  the  light  of  the  analysis,  some  of  the  recent  approaches  to 
software  development  (e.g.,  structured  programming,  top-down 
development,  chief  programmer  teams,  automated  tests)  are 
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examined.  The  performance  of  each  for  producing  cost/effective 
software  is  investigated. 


ARDEN72  CR25,286 

Arden,  B.W.,  Flanigan,  L.  K. ,  and  Galler,  B.  A.  ;  An  Advanced  System 
Programming  Course;  Proceedings  of  IFIP  Congress  71  (1972) 

pp. 1510-1514. 


ARVEY73 

Arvey,  R.D.,  Hoyle,  J.C.;  Evaluating  EDP  Personnel;  Datamation 
19,7  (July  1973)  pp. 69-73. 

One  of  the  major  problems  in  undertaking  a  project  to  produce  a 
large  program  is  the  reliability  of  the  personnel  involved.  The 
manager  of  such  a  project  must  have  information  about  the 
abilities  of  the  analysts  and  programmers  in  order  to  make  any 
intelligent  attempt  at  work  allocation  and  scheduling.  The  author 
discusses  his  experiences  in  tackling  this  problem  and  suggests 
avenues  of  approach  that  a  manager  faced  with  this  problem  could 
investigate. 


ASHCROFT7  2  CR24,932 

Ashcroft,  E.,  and  Manna,  Z.;  The  Translation  of  "go  to"  Programs 
to  "while"  Programs;  Proceedings  of  IFIP  Congress  71  (1972) 
pp. 250-255. 

This  paper  demonstrates  that  every  flowchart  program  can  be 
translated  into  an  equivalent  "while"  program  without  "go  to"s  and 
proves  that,  in  general,  new  variables  must  be  introduced  to 
preserve  certain  values  or  information  which  reflects  the  course 
of  computation. 


AUERBACH72 

Auerbach;  Documentation  Aids;  Auerbach  Standard  EDP  Reports; 

Auerbach  Info,  Inc.,  no.  8  (1972). 

This  is  an  extensive  and  essentially  complete  survey  of 
documentation.  Various  uses  of  documentation  during  project 
planning,  implementation  and  maintenance  are  described.  The 

elements  of  documentation  (e. g. ,  history  and  status,  glossaries, 
program  description,  equipment  and  software  environment)  are 
enumerated  and  justified.  Since  Auerbach  is  essentialy  a  software 
products  handbook,  the  main  focus  of  the  paper  is  on  what 
automatic  documentation  can  and  should  do  for  a  program.  The 

capabilities  of  text  and  comment  processing,  intention  abstraction 
and  graphical  flowcharting  or  paragraphing  are  investigated  in 

relation  to  the  components  of  a  program.  The  component 
descriptions  discussed  are  functional  relations,  data  bases,  files 
and  tables. 
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A V0TS73 

Avots,  J.;  Making  Project  Management  Work;  Datamation  19,1 
(January  1973)  pp. 42-45. 

The  article  discusses  the  human  and  technical  factors  (emphasizing 
the  former)  that  contribute  to  the  success  of  a  large  systems 
project.  Many  management  tools  for  project  scheduling  and 
reporting  are  available  or  may  be  developed.  For  large  projects 
they  will  be  computer-based.  However,  participation  in  planning 
and  a  common  understanding  of  procedures  and  goals  by  all  project 
members  is  essential  in  order  to  sustain  the  necessary  enthusiasm 
and  co-operation. 


BAKER72a  CR 23, 1 13 ; 2 4 ,6 53 
Baker,  F.T.;  Chief  Programmer  Team  Management  of  Production 
Programming;  IBM  Systems  Journal  11,1  (1972)  pp. 56-73. 

This  paper  combines  an  enunciation  of  the  principles  involved  in 
chief  programmer  team  organization,  and  the  problems  which  the 
approach  is  intended  to  solve,  with  a  description  of  how  the 
method  was  applied  to  a  particular  project;  an  information  bank 
system  for  the  New  York  Times.  The  general  specifications  for  the 
system  are  described,  and  an  outline  of  the  stages  of  development 
of  the  implementation  is  given,  to  demonstrate  the  correlation  of 
the  team  structure  with  the  way  in  which  the  problem  was  broken 
down  and  solved.  Statistics  are  given  to  indicate  how  the  various 
team  members  spent  their  time.  The  paper  concludes  with  a  review 
of  the  benefits  obtained  by  the  chief  programmer  team  approach  to 
the  project. 


BAKER  72b  CR25,203 
Baker,  F.T.;  System  Quality  Through  Structured  Programming; 
Proceedings  of  the  FJCC  41  (1972)  pp. 339-344. 

An  interesting  addition  to  the  literature  concerning  chief 
programmer  teams,  this  article  reiterates  the  principles  behind 
their  organization.  None  of  this  material  is  really  new,  but  the 
author  does  cite  some  previously  unpublished  statistics  obtained 
from  the  New  York  Times  information  bank  project.  The  figures 
indicate  the  numbers  of  errors  of  various  types  which  occurred  in 
various  parts  of  the  project.  Baker's  analysis  of  the  information 
supports  the  idea  that  rigorous  adherence  to  the  principles  of 
chief  programmer  teams  results  in  considerably  reduced  testing 
times  and  error  occurrences  after  product  delivery. 


BAKER72C  CR25,352 

Baker,  R.A.;  How  to  Write  Systems;  Computer  Bulletin,  16,11 
(November  1972)  pp. 534-536. 

A  humorous  look  at  avoiding  all  real  problems,  writing  "friendly" 
code,  and  muddling  through  the  middle  of  the  project  on  the  way 
from  the  end  to  the  beginning.  The  module  decomposition  criterion 
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of  Parnas  reappears  with  the  words  "put  the  code  least  likely  to 
succeed  off  by  itself.  Remember  that  you  will  be  back  again." 


BAKER  73 

Baker,  F.T.,  Mills,  H.D.;  Chief  Programmer  Teams;  Datamation  19,12 
(December  1973)  pp. 58-61. 

The  authors  assert  that  the  main  occupations  of  programmers  in  the 
traditional  management  structures  are  debugging  and  clerical 
chores.  The  chief  programmer  team  concept  is  presented  as  a  tool 
by  which  the  efforts  of  the  programmer  are  channeled  into  the 
tasks  of  design  and  programming  rather  than  debugging.  Integral 
to  this  concept  is  the  practice  of  structured  programming. 

The  authors  give  a  very  detailed  description  of  the  chief 
programmer  team  and  its  implementation,  drawing  on  considerable 
experience  to  illustrate  their  points. 


BAKER75 

Baker,  F.T.;  Structured  Programming  in  a  Production  Programming 
Environment;  IEEE  Transactions  on  Software  Engineering  SE-1,2 
(June  1975)  pp. 241-252. 

The  author  presents  the  full  structured  programming  techniques 
being  used  inn  large  programming  projects  at  IBM  FSD.  The  paper 
discusses  chief  programmer  teams,  top-down  development,  structured 
programming  and  development  support  libraries  as  the  four  basic 
changes  which  were  incorporated  at  IBM  FSD.  The  author  discusses 
each  technique  as  well  as  what  actual  implementation  of  each 
technique  has  shown. 


BARD72 

Bard,  Y.,  and  Suryanarayana ,  K.V.;  On  the  Structure  of  CP-67 

Overhead;  in  Freiberger,  W.  (ed.).  Statistical  Computer 
Performance  Evaluation.  Academic  Press  (1972). 

Regression  analysis  lives  again  in  this  thrilling  tale  from  the 
annals  of  IBM’s  history.  Still,  it's  a  good  way  to  determine 
actual  software  bottlenecks,  and  those  concerned  with  producing 
efficient  real-time  programs  should  probably  be  acquainted  with 
the  uses  of  the  technique. 


BARD73 

Bard,  Y.;  Experimental  Evaluation  of  System  Performance;  IEM 
System  Journal  12,3  (1973)  pp. 302-314. 

The  paper  reports  on  a  method  for  testing  system  performance, 
developed  to  be  used  as  part  of  an  evolutionary  operation 
technique  tc  improve  systems. 

The  performance  of  different  features  of  the  system  are  tested  by 
using  rapid  on-line  switching,  as  opposed  to  conventional  day-by- 
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day  switching,  of  the  various  versions.  This  technique  of  on-line 
switching  has  been  used  successfully  to  test  a  paging  replacement 
algorithm,  various  time-slicing  constants  and  the  effect  of 
assigned  priorities  on  the  user  in  a  time  sharing  system. 


BAETH74 

Earth,  C.W.;  Notes  on  the  case  Statement;  Software  -  Practice  and 
Experience  4,3  (July-September  1974)  pp. 289-298. 

A  brief  examination  of  the  history  of  the  case  statement,  as 
introduced  by  Hoare  and  Wirth.  The  paper  touches  on  the  problems 
of  the  earlier  version  and  their  solution  in  the  later  versions, 
and  culminating  in  yet  another  “natural  and  intuitive"  language 
extension  to  facilitate  “structured  programming"  (complete  with 
backwards-spelled  bracket! in g) .  The  author  proposes  (a)  a 
ccnditional  test  (Boolean  expression)  form  of  case,  and  (b)  a 
syntax  to  make  explicit  the  semantics  of  an  "out-of-r an ge"  case 
(i.e.,  whether  "no-operation"  or  "error"  is  to  result).  A 
readable  but  only  barely  informative  article  for  light  bedtime 
reading. 


B  ASU7  5a 

Basu,  S.K.,  and  Misra,  J. ;  Proving  Loop  Programs;  IEEE 
Transactions  on  Software  Engineering  SE-1,1  (March  1975)  pp. 76-86. 


B ASU7  5b 

Basu,  S.K.,  and  Yeh,  R.T.;  Strong  Verification  of  Programs;  IEEE 
Transactions  on  Software  Engineering  SE-1,3  (September  1975) 
pp. 339-345. 

The  authors  present  a  method  for  determining  if  a  predicate  is  a 
lcop  invariant  of  a  given  loop  by  determining  if  it  is  a  fixed 
point  of  a  particular  function.  Using  the  notation  developed  by 
Dijkstra,  they  examine  the  problems  in  proving  both  correctness 
and  termination  of  a  program  giving  interesting  results  relating 
the  partial  and  total  correctness  of  programs. 


B  AUER  72  CR2  5, 0  47 
Bauer,  F.L.;  Software  Engineering;  Proceedings  of  IFIP  Congress  71 
(1972)  pp. 530-538. 

A  definition  of  the  term  "software  engineering"  is  given  as  "the 
part  of  computer  science  which  is  too  difficult  for  the  computer 
scientist."  The  aims  of  software  engineering  are  discussed,  along 
with  reasons  for  adopting  these  aims,  and  the  problems  involved  in 
meeting  them.  The  role  of  education  in  the  introduction  of 
software  engineering  techniques  to  the  programming  community  is 
mentioned,  and  the  resultant  obsolescence  of  present  programming 
techniques  is  predicted.  Problems  involved  in  applying  techniques 
of  industrial  engineering  to  software  are  explored,  and  solutions 
for  some  are  offered.  The  role  of  structured  programming  as  a 
tool  for  application  of  those  techniques  is  investigated  at  some 
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length,  and  soie  problems  not  solved  by  this  tool  are  examined. 
The  concluding  remarks  present  some  ramifications  of  the 
techniques  and  philosophy  of  software  engineering  for  the 
programming  community,  and  point  out  the  need  for  comparative 
testing  and  more  widespread  discussion  and  use  of  these  points  in 
order  to  achieve  progress  in  the  field. 


BAUER  73  CR2 6, 1 97 

Bauer,  F.L.;  Software  and  Software  Engineering;  SIAM  Review  15,2 
part  2  (April  1973)  pp. 46 9-480. 

This  is  a  survey  paper  on  software  engineering.  It  is  discussed 
under  the  following  four  headings:  (1)  how  the  term  "software" 
developed;  (2)  how  software  was  (and  still  is)  developed;  (3)  how 
software  should  be  developed;  (4)  how  software  engineering  should 
develop  in  the  future.  Under  (1)  and  (2)  a  brief  history  of 
software  and  its  relation  to  computing  is  given  all  the  way  back 
to  Babbage.  Under  (3)  the  software  crisis  is  analysed  and 
suggestions  for  its  mastery  are  given.  Finally  under  (4)  the 
problems  of  educating  the  next  generation  of  programmers  are 
discussed. 


BAUER  76 

Bauer,  W.F.;  Software  Products:  The  Next  ten  Years;  Computers  and 
People  25,10  (October  1976)  pp. 8-10, 21. 

Citing  the  facts  that  from  1972-1976,  the  number  of  software 
companies  and  products  doubled,  and  that  the  software  industry  is 
immature  and  not  well  understood,  the  author  predicts  major 
changes  in  the  software  industry.  Some  of  these  are:  the  survival 
of  only  the  better  companies,  a  switch  in  emphasis  from  system  to 
application  products,  better  products  which  are  "off  the  shelf"  in 
nature,  transaction  based  pricing  and  the  introduction  of 
"firmware"  products.  Much  of  what  the  author  contends  seems  to 
depend,  to  a  degree,  on  current  litigation  involving  IBM. 


BENSON73 

Benson,  J.P.;  Structured  Programming  Techniques;  IEEE  Symposium  on 
Computer  Software  Reliability,  New  York  (April  1973)  pp. 143-1 47. 

The  paper  attempts  to  answer  the  question  "What  is  structured 
programming?"  by  examining  the  different  meanings  which  have  been 
associated  with  the  term.  Structured  programming  is  viewed  as  a 
design  methodology  by  examining  the  work  of  E.W.  Dijkstra  and 
H.D.  Mills.  It  is  viewed  as  a  coding  technique  (gotoless 
programming)  in  the  light  of  the  work  by  Bohm  and  Jacopini.  The 
paper  serves  as  a  good  (and  brief)  introduction  to  the  major  ideas 
of  structured  programming. 


B  ERR  Y  75 

Berry,  Daniel  M.  ;  Structured  Documentation;  SIGPLAN  Notices  10,11 
(November  1975)  pp.7-12. 
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The  author  suggests  that  traditional  program  documentation 
consisting  of  verbal  descriptions,  flowcharts,  and  comments  (VDFC) 
is  usually  of  marginal  help  in  understanding  programs.  Of  much 
mere  use  is  structured  documentation  that  describes  the  refinement 
process.  Since  the  author  feels  that  many  structured  programs  are 
not  developed  as  cleanly  as  their  designers  claim,  he  suggests 
that  the  structured  documentation  describe  the  logical  refinements 
in  the  finished  program  rather  than  the  actual  refinements  made 
during  program  development. 


BLOOM  75 

Bloom,  A.M.;  The  "ELSE”  must  go,  too;  Datamation  21,5  (May 
pp. 123-128. 


Bloom's  thesis  is  that  the  use  of  multiply-nested  IF-THEN 

complex 
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groups  leads  to  the  production  of  programs  which  are 
hard  to  maintain,  since  it  is  difficult  to  see 
conditions  under  which  a  given  section  of  code  is 
the  processing  associated  with  an  ELSE  clause 


that  of  an  IF  (NOT)-THEN  which  specifies  the  negation  of 
original  IF  condition,  the  ELSE  is  actually  unnecessary, 
advocates  the  use  of  "functional"  programming  -  in 
preparation  of  a  decision  table  indicating  combination 
conditions  under  which  specific  functions  are  to  be  perfo 
followed  by  direct  coding  from  the  table  using  IF-THEN, 
disadvantages  of  coding  duplication  and  run-time  inefficiency 
outweighed,  it  is  claimed,  by  the  more  economic  advantag 
debugging  and  maintenance  ease. 
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BOCHM ANN73a  CR26,098 
Bochmann,  G.V.;  Multiple  Exits  from  a  Loop  without  a  Goto;  CACM 
16,7  (July  1973)  pp. 443-444. 


The  author  proposes  another  control  construct  which  outside  of  the 
body  of  a  loop  distinguishes  between  normal  and  abnormal 
termination  of  the  loop.  This  appears  to  be  a  useful  control 
structure  extendable  to  the  searching  of  linked  lists. 


BCCHMANN73b 

Bochmann,  G.V.;  Hierarchical  Language  Definition;  SIGPLAN  Notices 
8,9  (September  1973)  pp. 50-51. 

The  author  describes  a  basic  methodology  for  implementing 
operating  systems  and  other  related  programs.  Starting  from  a 
basic  language  (machine  independent  but  implemented  on  each 
different  machine) ,  a  hierarchy  of  languages  is  described  each  of 
which  is  written  in  the  previous  language.  Only  when  implementing 
primitives  for  parallel  processes  does  the  real  machine  surface 
again  presumably  for  interrupts,  timing,  etc. 
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BCEHM73 

Boehm,  B.W.;  Software  and  its  Impact:  A  Quantitative  Assessment; 
Datamation  19,5  (May  1973)  pp. 48-59. 


B0EHM7  5a 

Boehm,  B.W.;  Software  Design  and  Structuring;  in  Horowitz, 
E .  (e d •  )  ,  Practical  Strategies  for  Developing  Large  Software 
Systems;  Addison- Wesle y  (1^75)  pp. 103-128. 

The  author  asserts  that  most  software  errors  can  be  traced  to 
faulty  design.  He  does  not  offer  a  panacea  for  improving  design, 
but  rather  classifies  recent  design  techniques  and  describes  the 
advantages  and  disadvantages  of  each.  The  techniques  considered 
are:  bottom-up  design,  top-down  stub,  top-down  problem  statement, 

structured  programming,  and  model-driven  design.  The  author 
suggests  that  a  synthesis  of  these  techniques  is  required  for  the 
best  software  design. 

Included  in  the  article  are  a  useful  taxonomy  of  the  causes  of 
software  errors  and  tables  showing  the  software  error  data 
analysis. 

BOEHM  75b 

Boehm,  B.W.,  McClean,  R.K.,  and  Urfrig,  D.  B. ;  Some  Experience  with 
Automated  Aids  to  the  Design  of  Large-Scale  Reliable  Software; 
IEEE  Transactions  on  Software  Engineering  SE-1,1  (March  1975) 
pp.  125-133. 

The  authors  describe  their  experiences  with  a  data-base  system 
which  stored  the  input-output  specifications  (number  of 
parameters,  range  of  each,  units,  etc.)  for  modules  of  a  large 
software  project.  The  system  checks  to  see  if  the  input 
specif ica tions  given  for  a  module  (givem  by  one  programmer)  match 
the  output  specifications  of  the  calling  module  (given  by  another 
programmer).  The  authors  feel  this  type  of  system  is  useful  in 
that  a  large  percentage  of  costly  errors  created  through  poor 
design  specifications  could  be  eliminated  in  this  manner.  The 
comments  are  relative  to  a  very  large  software  system. 


BRATM AN75 

Bratman,  H.;  Automated  Techniques  for  Project  Management  and 
Control;  in  Horowitz,  E.  (ed.).  Practical  Strategies  for  De vel oping 
Large  Software  Systems :  Addison-Wesley  (1975)  pp.  193-211. 

A  distinction  is  made  between  a  system  that  provides  automated 
aids  for  software  development  and  a  system  that  assists  in 
managing  the  development  of  software  projects.  The  emphasis  in 
this  paper  is  on  the  latter.  The  Automated  Project  Managers' 
Information  System  (APMIS)  is  integrated  with  a  software 
development  system  based  on  chief  programmer  teams  and  structured 
program  development.  APMIS  provides  the  manager  with  information 
on  the  progress  on  the  sysm  (including  design,  programming,  and 
testing) ,  chief  programmer  team  performance,  and  current  resource 
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expenditure.  The  author  does  not  provide  implementation  details. 
Hence,  it  is  reasonable  to  assume  that  APMIS  is  a  proposal  for 
discussion  rather  than  a  practical  reality. 


BRINCH  HANSEN72a 

Brinch  Hansen,  P.;  Structured  Multiprogramming;  CACM  15,7  (1972) 

pp.  574-57  8. 

The  author  presents  an  extension  to  the  programming  language 

PASCAL  to  permit  and  control  multiprogramming  in  a  structured 

manner.  He  introduces  the  concurrent  statement  COBEGIN  S1,S2,S3, 
CCEND  and  discusses  mutually  exclusive  operations  SI,  S2...  He 
permits  process  communication  via  shared  variables  and  "critical 
regions,"  introducing  a  REGION  group  not  unlike  a  DO  group,  but 
depending  on  a  shared  variable.  He  continues  from  here  to  the 
concept  of  an  event  variable  which  can  be  used  in  an  AWAIT 

statement  within  a  critical  region,  or  by  a  CAUSE  statement  in  a 

critical  region  based  on  the  same  shared  variable.  The  addition 
of  this  structure  to  these  concepts  greatly  clarifies  the  intent 
of  the  programmer  and  eases  proof  of  correctness. 


BRINCH  HANSEN72b 

Brinch  Hansen,  P. ;  A  Comparison  of  Two  Synchronizing  Concepts; 
Acta  Informatica  1  (1972)  pp.  190-199. 

The  author  examines  the  relative  merits  of  two  synchronization 
methods,  namely,  semaphores,  and  conditional  critical  regions. 
The  application  of  the  two  methods  is  outlined  on  the  writer- 
reader  problem  and  proofs  of  these  applications  are  presented. 

The  conclusions  the  author  reaches  suggest  that  the  ease  of 
applicability  of  either  method  depends  to  a  large  degree  on  the 
application.  Also  the  suggestion  is  made  that  the  conditional 
critical  region  concept  be  incorporated  as  a  primitive  into 
languages  that  are  designed  for  applications  involving  parallel 
processes. 


BRINCH  HA NSEN73a 

Brinch  Hansen,  P.;  Testing  a  Multiprogramming  System;  Software 
Practice  and  Experience  3,2  (April-June  1973)  pp. 145-150. 

A  brief  description  of  the  testing  of  the  operating  system 
described  in  [Brinch  Hansen  70].  The  difficulties  of  testing  such 
a  system  are  noted.  The  testing  mechanism,  consisting  of  two  very 
short  additions  to  the  system  kernel  code,  was  designed  before  the 
code  for  the  system  was  written.  Since  the  system  was  designed  in 
a  series  of  nested  "programming  layers,"  each  layer  is  tested  and 
debugged  by  initializing  the  system  with  a  set  of  test  processes 
which  provide  tests  of  all  of  the  functions  of  the  particular 
layer.  The  need  for  a  "systematic  set  of  reproducible  test  cases" 
as  part  of  the  documentation  of  any  large  program  is  noted. 
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BRINCH  HANSEN73b  CR26,104 

Brinch  Hansen,  P.;  Operat ing  Systems  Principles;  Prent ice- Hall, 
Inc.,  Englewood  Cliffs,  N.J.  (1973)  pp. 1-366. 

This  book  is  an  excellent  overview  of  the  problems  and  trade-offs 
inherent  in  operating  system  design;  it  also  details  the  current 
state  of  their  solution.  Chapters  two  and  three  present  an 
abstract  view  of  computation  processes,  both  sequential  and 
asynchronous.  Chapters  four  through  six  discuss  techniques  of 
implementing  processes  on  present-day  computers.  Chapter  seven 
outlines  the  emerging  field  of  protection,  and  chapter  eight 
describes  and  gives  a  critical  analysis  of  the  operating  system 
for  the  RC4000.  This  book  is  required  reading  for  anyone  who 
would  design  a  large  system,  or  would  like  to  know  how  such  a 
system  should  be  put  together. 


BBOOKS75 

Brooks,  F.P.,  Jr.;  The  Mythical  Man-Month;  Addison-W esley 
Publishing  Company  (1975)  pp. 1-195 

In  this  collection  of  15  essays,  the  original  manager  of  both 
System/360  (hardware)  and  OS/360  discusses  his  experiences  and 
insights  into  the  management  of  large  software  projects.  His 
thesis  is  that  large  software  projects  suffer  from  problems 
qualitatively  different  from  small  projects,  due  to  the  division 
of  labor  and  its  consequence;  dramatic  increases  in  communication 
requirements.  Some  of  the  schedule-destroying  aspects  of  large 
projects  are  covered,  including  design  inconsistencies  due  to 
size,  poor  time  estimates,  the  myth  that  the  man-month  is  an 
accurate  measure  of  programming  productivity,  and  others.  He 
concludes  that  the  most  important  goal  in  a  large  software  project 
is  maintaining  the  "conceptual  integrity"  of  the  system. 

The  book  is  fascinating,  not  only  because  of  the  unique  position 
of  its  author,  but  also  because  Brooks  has  managed  to  convey  what 
he  has  learned  in  an  entertaining  and  informative  manner. 


BROWN72 

Brown,  G.  deW.;  The  Forum;  Programming,  the  Quiet  Revolution; 
Datamation  18,3  (March  1972)  pp. 147-150. 

In  the  sixties  programmers  were  considered  by  the  public  and 
themselves  as  heroes,  capable  of  solving  any  problem.  In  order  to 
face  new,  complex  problems  successfully,  programmers  must  adopt  a 
more  disciplined  attitude,  and  be  more  concerned  with  quality. 

BRCWN73  CR2  6,746 
Brown,  A.R.,  Sampson,  W.A.;  Program  Debugging;  American  Elsevier, 
New  York  (1973)  pp. 1-166. 

A  short,  easily  read  text  which  discusses  some  of  the  problems  and 
techniques  for  debugging  large  programs.  It  is  a  bit  vague  -  even 
though  an  example  is  given  of  a  proposed  method  of  bug  correction. 
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It  gives  a  quick  overview  for  someone  new  to  the  field,  but 
provides  little  that  is  original.  The  article  by  P.C.  Poole 
[POOLE73]  is  better. 


BRCWN74  CR2  8,099 
Brown,  P.J.;  Programming  and  Documenting  Software  Projects; 
Computing  Surveys  6,4  (December  1974)  pp. 213-220. 

The  paper  briefly  discusses  the  four  steps  in  the  execution  of 
software  projects:  planning,  coding,  testing,  and  final  usage.  It 
is  suggested  that  use  of  high  level  language,  good  error 
diagnostics,  good  documentation,  flexible  design,  etc.  will  help 
in  producing  good  software.  The  author  attempts  to  describe 
precautionary  measures  for  writing  good  programs. 


BROWN  75 

Brown,  J.R.;  Getting  Better  Software  Cheaper  and  Quicker;  in 
Horowitz,  E.  ( ed . ) ,  Practical  Strategies  for  Developing  Large 
Software  Systems ;  Addison-Wesley  (1975)  pp. 131-154. 

This  paper  describes  a  variety  of  automated  facilities  that  could 
be  integrated  to  aid  in  program  development,  debugging,  testing, 
and  writing  of  comments.  For  program  development,  an  extended 
Fortran  (METAFOR)  is  used  for  writing  programs  that  make  extensive 
use  of  reliable  modules  from  library.  The  COMGEN  (Common 
Specification  Statements  Generator)  is  recommended  as  a  tool  for 
data  base  construction.  Automated  debugging  aids  (Code  Auditor, 
Singularity  Analyzer,  and  Units  Consistency  Analyzer)  and 
automated  testing  aids  (Product  Assurance  Confidence  Evaluator) 
are  described. 

A  description  is  provided  of  an  effective  method  of  program 
documentation  (Coordinated  Commentary  Programming) .  The  method 
uses  two  teams  of  programmers  with  documentation  tasks  specified 
in  such  a  way  as  to  provide  good  program  comments  and  reasonable 
assurance  cf  program  consistency  and  completeness. 


BURSTALL72  CR25,707 

Burstall,  R.M.;  Some  Techniques  for  Proving  Correctness  of 
Programs  which  Alter  Data  Structures;  Machine  Intelligence  7 
(1972)  pp. 23-50. 

This  paper  extends  the  work  of  Floyd  [ FLOYD67a  ]  and  others  in 
providing  techniques  for  proving  program  correctness  in  programs 
that  deal  with  data  structures  like  arrays,  lists,  and  binary 
trees.  The  paper  reviews  Floyd's  technique  of  using  flow  diagrams 
in  correctness  proofs.  Then,  after  describing  some  new  concepts 
which  deal  with  handling  the  data  structures,  Burstall  provides 
several  examples  of  program  proofs  using  Floyd's  method. 
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CR25, 353 
Langu  ages ; 


CHEAT  H  AM7  2a 

Cheatham,  T.E.;  The  Recent  Evolution  of  Programming 
Proceedings  of  IFIP  Congress  71  (1972)  pp. 298-313. 


CHEAT  HA  M7  2 1  CR23,734 
Cheatham,  T.E.,  and  Wegbreit,  B. ;  A  Laboratory  for  the  Study  of 
Automating  Programming;  Proceedings  of  the  SJCC  40  (1972)  pp.11- 
21. 

This  paper  deals  with  facilities,  tools  and  techniques  for 
automating  programming.  The  title  is  perhaps  explained  by 
defining  programming  as  a  process  of  producing  an  algorithm  or 
procedure  capable  of  performing  a  task  or  constructing  an  abstract 
object,  given  a  precise  specification  of  the  task  or  object.  As 
the  authors  see  it,  the  problem  with  software  production  does  not 
involve  coming  up  with  any  program,  but,  rather,  in  coming  up  with 
a  good  program.  Thus,  the  goal  of  the  laboratory  is  constructing 
good  programs,  for  real  life  and  "hard"  problems. 

The  programming  system  ECL  and  extensible  language  ELI  are 
discussed  as  the  basis  for  the  laboratory;  initial  operation  of 
the  lab  and  approaches  used  are  briefly  described.  Components  of 
the  lab  include  a  control  path  (in  a  multiprogramming  environment, 
this  is  the  interface  with  the  user),  a  programmable  theorem 
prover,  a  data  base  of  theorems  for  program  transformations,  a 
pattern  matcher,  backtracking  mechanism,  and  program  performance 
measurement  techniques. 


CLARK73 

Clark,  B.L.  and  Horning,  J.J.;  Reflections  on  a  Language  Designed 
to  Write  an  Operating  System;  SIGPLAN  Notices  8,9  (September  1973) 
pp.  52-56. 

The  authors  express  their  opinions  on  the  crucial  issues  in  the 
design  of  a  high-level  system  language,  based  on  experience  with 
Project  SUE.  Various  advantages  of  languages  emphasizing 
structure  (program  and  data),  redundancy,  and  efficiency,  over 
traditionally  used  machine  dependent  language  are  outlined.  An 
example  program  is  included  at  the  end  to  illustrate  the  above 
points . 


CLINT72 

Clint,  M.,  and  Hoare,  C.A.R.;  Program  Proving:  Jumps  and 
Functions;  Acta  Informatica  1,3  (1972)  pp. 214-224. 

The  authors  argue  for  the  validity  of  using  the  'goto*  construct 
in  two  special  cases,  namely,  as  a  means  of  exiting  a  very  deep 
loop  nest  and  as  a  failure  exit.  Their  arguments  are  supported  by 
a  proof  method  for  this  restricted  class. 

A  discussion  of  functions  and  function  calls  examines  the  special 
problems  that  these  constructs  present  to  program  proofs,  and 
leads  to  a  method  to  handle  these  cases. 
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The  paper  concludes  with  an  example  illustrating  the  methods 
outlined. 


CIINT73  CR27,211 
Clint,  M.;  Program  Proving:  Coroutines;  Acta  Informatica  2  (1973) 
pp. 50 -63 . 

This  paper  discusses  an  extension  to  the  proof  rules  and  axioms 
given  by  Hoare,  so  that  Simula-like  coroutines  can  be  handled. 
The  new  proof  rule  is  stated  and  its  use  illustrated  by  an 
example.  The  paper  is  not  of  much  interest  to  the  general  reader, 
for  it  adds  no  new  concepts  to  previous  work.  However,  this  is 
not  to  say  the  paper  is  without  content  and  it  is  interesting  to 
know  that  the  methodology  can  be  extended  to  further  constructs. 


COHEN  72 

Cohen,  A.;  Modular  Programs:  Defining  the  Module;  Datamation  18,1 
(January  1972)  pp. 34-37. 

Modular  programming  is  a  useful  tool  if  applied  skillfully.  The 
author  gives  a  feeling  for  the  right  decomposition  of  your  problem 
into  modules  by  considering  typical  file  processing  programs. 


COHEN  7 4 

Cohen,  J. ,  and  Zuckerman,  C.;  Two  Languages  For  Estimating  Program 
Efficiency;  CACM  17,6  (June  1974)  pp. 301-308. 


COLE7  3 

Cole,  N.  M.  ,  and  Seikel,  M.J.;  Solving  a  Software  Design  Problem 
Using  Plain  English;  Datamation  19,10  (October  1973)  pp. 101-1 06. 

This  article  describes  a  method  of  top-down  program  design.  Plain 
English  is  not  really  used,  but  rather  a  high-level  macro 
language.  The  macros  are  written  by  top-level  programmers 
familiar  with  the  system,  and  the  information  content  of  the 
macros  is  such  that  low-level  programmers,  who  lack  the  detailed 
knowledge  of  the  system,  can  flowchart  and  code  the  program 
without  too  much  difficulty.  The  authors  claim  savings  in  time, 
increased  efficiency,  and  more  effective  use  of  programmer 
resources. 


COOK76 

Cook,  J.A.;  Experience  With  Extensible,  Portable  FORTRAN 
Extensions;  SIGPLAN  Notices  11,9  (September  1976)  pp. 10-17. 

Portability  and  compatibility  are  issues  that  are  highly  important 
yet  have  been  neglected.  One  solution  is  to  have  programmers 
restrict  themselves  to  a  subset  of,  a  language  supported  by  all 
compilers  for  that  language  and  machine.  In  FORTRAN  this  could  be 
the  1966  ANSI  standard  or  a  subset  called  PFORT.  The  author's 
solution  is  MORTRAN,  a  macro  preprocessor  for  FORTRAN  where  user 
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programs  written  in  MORTRAN  are  expanded  tp  meet  the  PFOET 
standard.  The  advantage  of  this  approach  is  that  any  language 
extensions  maye  implemented  with  a  user-defined  macro  and  still 
maintain  portability.  Anyoae  concerned  with  program  portability 
could  well  benefit  from  reading  this  article. 


COOK  E  75a 

Cooke,  J.E.r  and  Bunt,  R.B.;  Human  Error  in  Programming  as  a 
Result  of  Conventional  Training  Methods;  Software  Engineering 
Education  Proceedings,  IBM  Scientific  Symposium,  Montebello, 
Quebec  (May  1975)  pp. 63-69. 

This  paper  provides  a  useful  analysis  of  programming  as  a  human 
activity.  The  authors  identify  five  phases  of  the  activity: 
problem  analysis,  solution  definition,  program  implementation, 
testing,  and  maintenance.  They  demonstrate  that*  for  each  phase 
current  practices  of  training  programmers  tend  to  result  in  the 
production  of  unreliable  software.  They  conclude  that  the  current 
emphasis  on  producing  syntactically  correct  programs  should  be 
changed.  Training  should  emphasize  the  adherence  to  a  defined  set 
of  procedures  with  continuous  monitoring  and  interaction  with 
other  humans. 


COOKE75b 

Cooke,  J.E.,  and  Bunt,  R.B.;  Human  Error  in  Programming:  The  Need 
to  Study  the  Individual;  INFOR  13,3  (October  1975)  pp. 296-307. 

The  authors  list  three  levels  of  human  effects  on  programming  -- 
the  interactions  within  a  programming  group,  the  personality  of 
the  individual  programmer,  and  the  capability  of  the  programmer  as 
a  human  information-processing  system.  After  reviewing  literature 
dealing  with  the  current  programming  technigues  and  styles,  the 
authprs  state  that  there  exists  a  need  for  experimental  studies  of 
the  information  processing  limitations  of  the  programmer  —  in 
particular,  eye  movement,  perception,  and  short-term  memory.  Some 
problems  of  methodology  are  considered,  and  an  experimental 
approach  is  suggested. 


CQFBAT07  2  CR25,199 
Corbato,  F.J.,  Saltzer,  J.H.,  and  Clihgen,  C.T.;  MDLTICS  -  The 
First  Seven  Years;  Proceedings  of  the  SJCC  40  (1972)  pp. 571-583. 

Although  intended  as  a  review  and  current  status  report,  this 
paper  provides  an  interesting  description  of  the  progress  of  the 
design  and  implementation  of  a  very  large,  very  complex  research 
project  with  real  life  goals.  In  their  conclusions,  the  authors 
make  the  point  that  computer  utility  systems  must  evolve,  since 
the  costs  of  redesign  and  re- implementation  are  too  high  to  allow 
any  ether  procedure.  This  is  almost  certainly  true  of  any  very 
large,  complex  system  which  is  to  serve  a  community  of  users  who 
( 1)  will  not  wait  for  the  ultimate  to  arrive  at  the  expense  of  not 
doing  anything  until  it  does;  (2)  are  used  to  a  particular 
environment,  and  see  no  real  need  to  unlearn  everything. 
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CUNN INGHAM76 

Cunningham,  E.J.  and  Pugh,  C.G.;  A  Language-independent  System  to 
Aid  the  Development  of  Structured  Programs;  Software  -  Practice 
and  Experience  6,4  (Octob er-December  1976)  pp. 487-503. 

This  paper  presents  the  authors'  attempt  at  a  generalized  language 
independent  program  development  aid  for  stepwise  refinement. 
Their  system,  GLIDE,  is  an  interactive  one  and  allows  users,  in 
addition  to  standard  editing  features,  to  save  all  versions  of  a 
program  throughout  its  development  history.  It  also  allows  users 
to  include  in  the  program  a  delay  feature  for  procedures  which 
will  be  defined  at  a  later  time.  Unfinished  programs  with  delayed 
procedures  may  be  compiled  and  run  with  any  of  a  number  of 
compilers.  Run  time  features,  because  they  are  generally  language 
dependent,  are  not  part  of  the  GLIDE  system.  This  system  provides 
an  environment  for  the  programmer  where  stepwise  refinement  is  not 
only  easy  but  even  encouraged* 


DAHL72 

Dahl,  O.J.,  and  Hoare,  C.A.R.;  Hierarchical  Program  Structures;  in 
Dahl,  O.J. ,  Dijkstra,  E. W. ,  and  Hoare,  C.A.R.,  Structured 
P rogramming.  Academic  Press,  New  York  (1972)  pp.  175-220. 

This  paper  describes  an  elegant  merging  of  structured  data  and 
control  concepts  in  the  "class"  construct  of  the  SIMULA  67 
language.  Examples  are  given  to  show  how  a  class  may  be  used  to 
represent  a  general  data  structure  and  operations  on  it  and  how 
specific  instances  of  the  structure  may  be  generated. 
Demonstration  is  also  given  of  the  use  of  the  class  concept  for 
the  implementation  of  coroutines.  The  exposition  is  somewhat 
weakened  by  the  stress  placed  on  the  use  of  the  language  for 
simulation  studies,  and  by  the  fact  that  the  language  designers 
felt  it  necessary  to  make  variables  of  a  class  object  accessible 
from  outside  the  object.  Nonetheless,  the  concepts  presented  are 
certainly  worthy  of  further  attention,  particularly  with  a  view 
toward  restoring  locality  of  data  to  the  class. 


DAKIN  73 

Dakin,  R.J.,  and  Poole,  P.C.;  A  Mixed  Mode  Approach;  The  Computer 
Journal  16,3  (August  1973)  pp. 219-222. 

This  paper  uses  the  development  of  a  version  of  the  MITEM  text 
editor  to  describe  the  notion  of  mixed  coding.  This  consists  of 
using  interpretive  and  direct  code  in  the  same  system.  Also 
discussed  are  the  adaptability  of  code  generation,  selective 
optimization  of  run  time  and  program  space  in  code  generation. 

The  system  was  first  run  interpreti vely  and  monitored,  to  discover 
that  97%  of  the  execution  time  was  spent  in  less  than  ten  per  cent 
of  the  source  code.  These  frequently  executed  portions  were 
changed  to  direct  code,  and  the  rest  of  the  code  was  left 
interpretive.  This  mixture  combines  the  speed  of  direct  code  and 
the  efficient  space  utilization  of  interpretive  code.  The  run-time 
overhead  of  mixed  code  was  found  to  be  very  slight  and  it  ran 
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three  to  five  times  faster  than  the  interpretive  code,  while  being 
only  10-2051  slower  than  the  direct. 

Another  benefit  which  is  discussed  is  the  adaptability  of  the 
software  which  is  created.  Also,  having  some  interpretive  code 
allows  powerful  debugging  and  easy  monitoring  capabilities. 
Finally,  the  authors  give  some  ideas  on  how  a  mixed  code  software 
development  system  might  operate. 


D ARLINGTON76 

Darlington,  J.,  and  Burstall,  R.M.;  A  System  which  Automatically 
Improves  Programs;  Acta  Informatica  6,1  (1976)  pp. 41-60. 

With  the  current  emphasis  on  software  engineering,  programs  are 
frequently  me  easy  to  understand  (readability)  at  the  expense  of 
efficiency.  The  authors  are  developing  a  system  to  mechanically 
convert  some  of  the  more  readable  high  level  operations  into  more 
efficient  lower  level  operations. 

They  have  developed  algorithms  for  recursion  removal,  elimination 
of  redundant  computation,  replacement  of  procedure  calls  by  their 
bodies,  and  compile-time  garbage  collection.  The  algorithms  have 
been  inplemented  as  POP-2  programs  for  an  interactive  system 


DE  BALBINE75 

de  Balbine,  G.;  Better  Manpower  Utilization  Using  Automatic 
Restructuring;  AFIPS  Conference  Proceedings  44  (1975)  pp. 319-327. 

This  paper  describes  an  implemented  "structuring  engine"  that 
mechanically  restructures  programs  written  before  the  advent  of 
structured  programming.  Fortran  program  are  translated  into  S- 
Fortran  (an  extension  of  Fortran  with  structuring  concepts).  The 
purpose  of  the  process  is  to  produce  programs  that  are  less  costly 
tc  maintain  because  they  ae  more  readable.  To  achieve  the 
purpose,  the  author  avoids  a  mechanical  translation  into  a  GOTO- 
less  program  by  adding  Boolean  variables.  Such  a  translation  is 
probably  less  readable.  Instead,  he  allows  some  constrained  forms 
of  the  GOTO  (e.g.,  UNDO)  that  improve  readability. 


DEMILL076 

DeMillo,  R.A.,  Eisenstat,  S.C.,  and  Lipton,  R.J.;  Can  Structured 
Programs  Be  Efficient?;  SIGPLAN  Notices  11,10  (October  1976) 

pp . 1 0- 1 8 . 

The  authors  have  shown  that  various  control  structures  have 
differing  power  under  their  notion  of  simulation  of  a  program. 
(Simulation  is  rewriting  a  program  use  certain  control  structures 
to  replace  the  original  ones).  These  provable  differences  in 
power  have  yielded,  for  the  first  time,  quantitative  information 
about  control  structures.  The  power  of  constructs  is  found  in 
relation  to  program  efficiency.  A  sample  case  is  given  showing 
the  difference  between  goto  programs  and  programs  allowing 
ra ult ip le  loop  exits  from  any  depth  of  nesting.  The  simulation  is 


-24- 


Current  Articles 


found  to  be  space-time  dependant;  i.e.,  the  goto  programs  can  only 
be  simulated  by  the  structured  programs  at  the  cost  of  very  large 
increase  in  the  size  of  the  program  or  by  large  increase  in 
execution  time. 


DENIL73 

Denil,  N.J.;  Software  Design  with  Invocation  Diagrams;  SIGPLAN 
Notices  8,9  (September  1973)  pp. 57-59. 

The  author  describes  a  medium  for  expressing  abstractions  of 
programs  (especially  their  structure) .  He  claims  programs  can  be 
designed  top  down  with  this  medium;  only  the  "logic  of  the  design" 
is  crucial.  The  medium  provides  for  diagrams  of  data  and 
structure  of  the  programs  as  observed  from  the  program  modules, 
the  data  communicated  between  modules,  and  the  effects  each  module 
has  on  the  communicated  data. 


DENNIS75 

Dennis,  J.B.;  First  Version  of  a  Data  Flow  Procedure  Language; 
MIT,  Project  MAC  Technical  Memorandum  61  (May  1975)  pp.1-21. 

In  this  paper  Dennis  describes  a  language  for  representing 
computational  procedures  based  on  the  concept  of  data  flow.  The 
language  is  presented  in  terms  of  a  semantic  model  that  permits 
concurrent  execution  of  noninterfering  program  parts.  The 
language  is  able  to  effectively  represent  block  structured 
programs.  It  is  also  consistent  with  the  concept  of  modular 
programming,  but  has  not  yet  been  extended  to  provide  appropriate 
means  for  supporting  the  notion  of  function  clusters  as  proposed 
by  Liskov  and  Zilles. 

The  paper  gives  an  excellent  introduction  to  the  concept  of  data 
flow  languages,  which  are  being  researched  by  the  Computation 
Structure  Group  at  project  MAC,  in  an  effort  to  study  the  design 
of  a  "common  base  language".  (The  base  language  contributes 
significantly  to  the  ability  of  computer  users  to  easily  construct 
correct  programs.)  The  data  flow  language  is  being  used  as  a  model 
for  study  cf  fundamental  semantic  constructs  for  programming,  as  a 
target  language  for  evaluating  translatabilit y  of  programs 
expressed  at  the  user-language  level,  and  as  a  guide  for  research 
in  advanced  computer  architecture. 


DEREMER75 

DeRemer,  F.L.,  and  Kron,  H.;  Programming-in-the-small  versus 
Programming-in-the-large;  International  Conference  on  Reliable 
Software,  SIGPLAN  Notices  10,6  (June  1975) 

The  authors  of  this  paper  distinguish  two  types  of  programs: 
"small"  programs  of  less  than  a  few  pages  in  length  and  easily 
comprehended  by  a  single  programmer,  and  "large"  programs,  which 
include  all  others  but  usually  mean  systems  containing  other 
modules,  perhaps  written  by  several  different  programmers.  They 
argue  that  today’s  languages  are  adequate  only  for  progra mming-in- 
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the-small,  and  that  a  new  language  is  needed  to  specify  how 
smaller  modules  are  linked  together  to  form  a  system. 

A  prototype  language  called  MIL/1  is  described.  Advantages 
include  a  compiler  checkable  specification  of  a  greater  amount  of 
the  intent  of  the  programmer;  tools  for  project  management  and 
documentation;  and  a  means  of  communication  between  members  of  a 
programming  team,  especially  a  chief  programming  team. 


DEUTSCH72 

Deutsch,  P.,  and  Grant,  C.A.;  A  Flexible  Measurement  Tool  for 
Software  Systems;  Proceedings  of  IFIP  Congress  71  (1972)  pp.320- 
326. 


DIJKSTRA72a  CR24,552 
Dijkstra,  E.W.;  The  Humble  Programmer;  CACM  15,  10  (October  1972) 
pp. 859-866; 

The  author  reflects  on  the  historical  development  of  programming. 
Initial  hardware  constraints  and  the  nature  of  the  slowly 
developing  field  resulted  in  puzzle-minded  programmers  who 
optimized  the  computing  process.  The  introduction  of  second  and 
third  generation  computers  only  heightened  the  problems. 

In  looking  to  the  future  he  foresees  that  projects  that  are  of 
limited  size  will  be  done  with  much  less  effort  and  many  fewer 
bugs.  This  will  be  accomplished  by  limiting  ourselves  to 
"intellectually  manageable  programs."  A  number  of  reasons  for  this 
are  given,  as  well  as  some  impediments.  To  be  humble  programmers, 
it  is  necessary  to  realize  the  magnitude  of  the  problems,  the 
usefulness  of  the  tools,  and  the  limitations  of  the  human  mind. 


DIJK  S  TRA  7  2b  CR26,364 
Dijkstra,  E.W.,  Notes  on  Structured  Programming,  in  Dahl,  O.J., 
Dijkstra,  E. W. ,  and  Hoare,  C.A.R.,  Structured  Program  ming ; 
Academic  Press,  New  York  (1972)  pp.1-82. 

This  first  section  of  the  book  is  by  Dijkstra,  and  entitled  "Notes 
on  Structured  Programming."  It  is  an  informal  set  of  notes  he 
wrote  to  himself  while  contemplating  the  problems  of  programming. 
The  notes  are  informal  in  that  they  tend  to  meander  through  the 
topic,  but  display  considerable  formality  in  the  presentation  of 
any  one  idea.  The  initial  comments  on  the  probability  of  a 
program  being  correct  are  based  on  shaky  premises.  The  sections 
on  top-down  programming  are  worthwhile.  The  last  section  seems 
designed  to  convince  the  reader  that  programming  style  can  be 
taught  successfully. 

DIJKSTRA73 

Dijkstra,  E.W.;  A  Simple  Axiomatic  Basis  For  Programming  Language 
Constructs;  EWD372,  Technological  University,  Eindhoven  (1973). 
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An  axiomatic  basis  for  programming  language  constructs  and  theit 
impact  on  efforts  to  prove  programs  correct  is  discussed. 
Starting  with  the  desired  result  expressed  as  a  postcondition 
predicate  P,  he  derives  the  weakest  precondition  for  a  construct 
such  that  after  execution  of  the  construct,  P  is  satisfied.  The 
axioms  for  the  derivations  are  described  for  many  (including  the 
most  useful)  constructs,  including  recursion.  The  main  advantage 
of  this  approach  is  that  it  appears  mathematically  simpler  than 
similar  approaches  to  this  problem. 


DI JKSTR A75a 

Dijkstra,  E.W.;  On  the  Teaching  of  Programming,  i.e. ,  On  the 
Teaching  of  Thinking;  Software  Engineering  Education  Proceedings, 
IBM  Scientific  Symposium,  Montebello,  Quebec,  (May  1975)  pp.112- 
120. 

Dijkstra  presents  his  ideas  on  the  framing  of  the  mind.  His  main 
concern  is  that  "pondering",  the  inductive,  trial  and  error  type 
of  thought  that  goes  with  any  complex  problem,  must  also  be  taught 
along  with  deductive  "reasoning".  Further,  he  mentions  the 
concept  of  "Revolt",  the  ability  to  recognize  an  inadequacy  in  the 
problem  as  opposed  to  the  problem  solver. 


DI JKSTRA7  5b 

Dijkstra,  E.W.;  Guarded  Commands,  Non-determinacy  and  a  Calculus 
for  the  Derivation  of  Programs;  Proceedings  International 
Conference  on  Reliable  Software,  SIGPLAN  Notices  10,6  (June  1975) 

p  p • 2—  2.13. 

After  giving  the  syntax  for  guarded  commands  (a  boolean  expression 
controlling  the  execution  of  an  associated  statement) ,  a 
repetition  construct,  and  an  alternative  construct,  the  author 
uses  the  "wp"  predicate  transformer  to  give  the  semantics  of  the 
constructs  (independent  of  any  machine  and  non-de ter ministic ) . 
Two  examples  are  then  given  demonstrating  his  calculus  based  on 
the  guarded  command  concept  and  the  "wp"  transformer.  Although  it 
is  debatable  whether  or  not  the  calculus  is  functional,  its 
advantage  is  that  it  allows  the  programmer  to  have  confidence  in 
the  correctness  of  his  program. 


D I JKSTR A7  5c 

Dijkstra,  E.W.;  Correctness  Concerns  and.  Among  Other  Things,  Why 
They  Are  Resented;  Proceedings  International  Conference  on 
Reliable  Software,  SIGPLAN  Notices  10,6  (June  1975)  pp. 546-550. 

The  author  waxes  philosophical,  giving  impressions  of  the 
intellectual  history  of  Computing  Science;  claiming  the  existence 
of  confusion  in  the  field  along  the  lines  of  "the  greater  our 
knowledge,  the  better  our  understanding".  He  goes  on  to  list  some 
of  the  progress  in  reliability,  starting  with  the  recognition  of  a 
problem  at  the  NATO  Conference  of  1968,  through  to  emphasis  on 
program  design  and  the  cleaning  up  of  program  languages  by  those 
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’’proof  guys".  Very  interesting  reading  from  one  so  prominent  in 
the  field. 


DIJKSTRA76 

Dijkstra,  E.W.;  A  Discipline  of  Programming ;  Prentice-Hall  (1976) 
pp. 1-217. 

In  this  book,  the  author  first  defines  the  notion  of  weakest 
predecessor  predicate  transformer  and  his  guarded  command  concept 
as  previously  developed  in  "Guarded  Commands,  Non-Determinacy ,  and 
a  Calculus  for  the  Derivation  of  Programs".  He  then  proceeds  to 
defend,  by  example,  beginning  with  simple  algorithms  such  as 
Euclid's,  and  ranging  through  "Updating  a  sequential  file"  to  "The 
problem  of  the  convex  hull  in  3  dimensions".  The  richness  of  his 
examples  leaves  no  doubt  as  to  the  success  of  his  defence. 

The  content  of  this  book  enables  programming  to  be  considered  a 
mathematical  discipline,  so  that  one  can  make  precise  and  exact 
statements  about  the  programs  so  derived. 


DONAHUE75 

Donahue,  J.E.;  Mathematical  Semantics  as  a  Complementary 
Definition  for  Ax iomatically  Defined  Programming  language 
Constructs;  in  Three  Approaches  to  Reliable  Software;  Language 
Design,  Dyadic  Specification,  and  Complementary  Semantics; 
Technical  Report  44,  Computer  Systems  Research  Group,  University 
of  Toronto  (January  1975). 

Hoare's  axiomatic  definitions  of  programming  language  semantics 
have  been  the  most  fruitful  approach  to  proving  program 
correctness.  In  certain  other  respects,  however,  the  axiomatic 
approach  has  proven  deficient:  it  may  conceal  certain  semantic 
aspects,  and  it  does  not  provide  a  useful  implementation  model. 
The  author  argues  that  the  "mathematical  semantics"  of  Scott  and 
Strachey  provides  a  useful  complementary  definition  technique  to 
the  axiomatic  approach.  The  question  of  demonstrating  the 
consistency  of  mathematical  and  axiomatic  definitions  is 
addre  ssed. 


EISPAS72  CR2  5,396 
Elspas,  B.,  Levitt,  K.N.,  Waldinger,  R.J.  and  Wakeman,  A.;  An 
Assessment  of  Techniques  for  Proving  Program  Correctness; 
Computing  Surveys  4,2  (June  1972)  pp. 97-147. 

An  excellent  survey  of  proof  techniques  of  interest  to  both  the 
person  unexposed  to  program  verification  techniques  and  as  an 
overview  for  the  person  actively  interested  in  this  area.  The 
article  reviews  both  formal  and  informal  approaches  to  program 
verification  in  some  detail,  including  work  by  Floyd,  Hoare, 
Manna,  London  and  many  others. 
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ERSHOV72  CR24,022 
Ershov,  A.P.;  Aesthetics  and  the  Human  Factor  in  Programming;  CACM 
15,  7  (July  1972)  pp. 501-505. 


FEURMAN76 

Feurman,  M.,  Dallal,  M.R.,  and  Liebling,  L.  ;  Structured 
Programming  in  COBOL  Under  IBM  360/370  OS;  SIGPLAN  Notices  11,8 
(August  1976)  pp. 16-30. 

This  paper  describes  the  authors*  experiences  in  using  a  number  of 
structud  programming  and  software  engineering  techniques  in  the 
writing  of  a  COBOL  edit  program.  It  follows  the  program  from 
problem  definition  to  completion  describing  the  methodology  used 
at  each  stage.  The  claim  made  is  thAt  the  resulting  program  is 
both  easy  to  read  and  highly  maintainable.  The  paper  is  little 
more  than  a  simple  description  and  makes  no  attempt  to  offer  new 
insights  into  programming  methodology  but  it  does  show  established 
techniques  can  be  applied  to  a  commercial  environment. 


FIENT73 

Fient,  H.G.;  Management  of  the  Acquisition  Process  for  Software 
Products;  Management  Informatics  2,3  (June  1973)  pp. 153-1 64. 

A  discussion  of  software  brokerage  as  a  possible  solution  to  the 
increasing  cost  of  software  development  and  the  rising  tendency  to 
buy,  rather  than  develop,  application  software  with  the  consequent 
dissatisfaction  resulting  from  lack  of  standards  and  control.  The 
article  gives  the  pros  and  cons  of  writing  one’s  own  software  and 
an  overview  of  the  software  product  market  giving  sources  of 
supply  and  information  and  listing  typical  user  and  supplier 
complaints.  A  detailed  breakdown  of  the  requirements  typically 
encountered  is  given  covering  costs,  design,  ease  of  use, 
maintenance,  testing,  documentation  and  contracting.  Finally  a 
description  of  software  brokerage  detailing  services  provided  to 
user  and  supplier  is  given. 


FISHER72 

Fisher,  D.A.;  A  Survey  of  Control  Structures  in  Programming 

Languages;  SIGPLAN  Notices  7,11  (November  1972)  pp.1-14. 

This  paper  examines  the  control  structures  of  programming 

languages  and  how  the  constructs  are  developed.  Progress  has  been 
made  by  specialization  through  composition  of  a  few  very  general 
primitive  operations.  The  dominance  of  the  underlying  sequential 
machine  is  apparent  throughout  this  process.  In  some  areas  this 
specialization  has  lead  to  clarity  and  efficiency,  while  in  others 
the  accompanying  loss  of  generality  has  had  the  opposite  effect. 


FLON76 

Flon,  L. ,  and  Haberman,  A.N.;  Towards  the  Construction  of 
Verifiable  Software  Systems;  Proceedings  of  Conference  on  Data, 
SIGPLAN  Notices  Special  Issue  (1976)  pp. 141-148. 
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This  paper  is  mainly  concerned  with  the  use  of  abstract  data  types 
to  aid  in  the  task  of  program  verification.  Abstract  data  types 
provide  an  important  design  tool  and  also  allow  certain  assertions 
to  be  made  about  a  program  that  are  difficult  to  prove  in  any 
other  way.  In  particular,  path  expressions  (an  ordered  sequence 
of  data  type  operations)  can  be  used  to  solve  problems  of 
operating  system  concurrence  and  still  allow  the  code  to  be 
verifiable.  This  paper  makes  several  assertions  about  what 
abstract  data  type  can  do  to  aid  program  verification  but  proves 
them  using  only  a  very  selected  set  of  examples. 


FLOYD72  CR2  5,232 

Floyd,  R.W.;  Toward  Interactive  Design  of  Correct  Programs; 
Proceedings  of  IFIP  Congress  71  (1972)  pp.7-10. 

An  imagined  interaction  between  a  computer  programmer  and  his 
machine  is  described,  in  which  the  computer  checks  the  program  for 
consistency  with  the  programmer's  stated  intentions,  and  proves 
the  logical  or  semantic  correctness  of  the  program  at  various 
levels. 


FONG73 

Fong,  E.N.;  Improving  Compiler  Diagnostics;  Datamation  19,  4 

(April  1973)  pp. 84-86. 

Most  of  a  programmer's  effort  in  program  development  is  spent  in 
debugging.  The  author  suggests  some  debugging  and  monitoring 
facilities.  These  are  divided  into  three  different  groups. 
Compile-time  checks  include  syntax  checking,  cross  reference 
listing,  modularity,  paragraphing,  and  static  control  concordance. 
Formal  and  actual  argument  checks  and  static  subroutine  analysis 
can  be  performed  at  link/load  time.  Execution- time  checks  include 
dynamic  traces  of  subroutine  calls,  flow  of  control,  and  variables 
in  addition  to  snapshot  dumps  and  address  checking. 


F0SDICK72 

Fosdick,  L.D.;  The  Production  of  Better  Mathematical  Software; 
C  ACM  15,7  (July  1972)  pp. 611-617. 

In  this  article  a  number  of  suggestions  are  made  for  future  work 
in  the  area  of  software  production.  Although  it  is  ostensibly 
oriented  towards  the  problem  of  the  production  of  mathematical 
software,  it  is  not  particularly  dependent  on  any  peculiarities  of 
this  class  of  software.  The  suggestions  are  divided  into  the  areas 
of  design,  validation,  documentation  and  standards.  It  points  out 
the  strong  coupling  between  these  areas.  It  completely  ignores  the 
questions  of  the  organization  and  mechanics  of  the  production  of 
software,  such  as  is  treated  in  Mills  and  Baker. 

The  article  is  uneven  and  perhaps  too  shallow  in  its  treatment  of 
the  problems  in  the  areas  discussed,  but  it  is  provocative.  It 
suggests  in  simple  terms  the  areas  that  every  programmer  must 
consider  if  he  is  to  be  able  to  be  at  all  successful  in  producing 
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worthwhile  programs.  It  provides  a  first  crack  at  a  reading  list 
for  programmers  in  support  of  their  professional  responsibilities. 
One  very  interesting  idea  emerges  from  the  article  and  that  is  the 
idea  of  truly  automatic  program  documentation,  the  latter  to  be 
interpreted  in  a  broad  sense. 


FREEMAN73 

Freeman,  P.;  Functional  Programming  Testing  and  Machine  Aids;  in 
Hetzel,  W.C. (ed.).  Program  Test  Methods;  Prentice-Hall  (1973) 
pp. 49-56 . 


After  reviewing  the  types  of  functional  programming  proposed  by 
Dijkstra,  Parnas,  and  Mills,  the  author  proposes  a  rich 
"integrated  programming  environment"  for  the  continual  testing  of 
structured  programs  during  their  design  and  development.  It  is  an 
environment  that  includes  editors,  filing  systems,  compilers,  and 
so  on,  similar  to  the  environment  provided  by  most  interactive 
BASIC  systems.  The  environment  is  not  fully  described  in  this 
paper,  but  brief  sketches  of  important  aspects  (e.g.  "level  of 
control")  are  provided.  Two  mechanisms  for  implementation  of  the 
system  are  also  described. 


The  author  suggests  that  the  extra  expense  of 
must  be  compared  to  the  cost  of  producing 
without  such  an  environment 


the  rich  environment 
incorrect  programs 


FRIEND75 

Friend,  J.;  Programs  Students  Write;  Technical  Report  257, 
Psychology  and  Education  Series,  Institute  for  Mathematical 
Studies  in  Social  Science,  Stanford  University,  California  (July 
25,  1975)  pp. 1-281. 

An  automated  system  of  instruction  for  the  BASIC-like  AID  language 
is  designed  and  the  problem-solving  behaviour  of  forty  college 
students  is  studied  using  the  system.  The  system  consists  of  a 
program  that  presents  the  instructional  material  and  an 
interpreter  with  which  the  student  interacts  when  writing 
programs.  Student  responses  are  recorded  during  interaction  for 
later  analysis. 

This  paper  is  of  interest  because  the  attributes  required  by  the 
automated  system  corresponds  to  some  of  the  goals  of  the  software 
engineer.  The  automated  system  must  analyze  students*  programs 
for  syntax  errors  and  correctness.  It  must  guide  the  student  in 
the  development  of  a  reliable  program. 

As  well  as  describing  the  system  operation  in  detail,  the  author 
describes  methods  used  for  determining  correctness,  partial 
correctness,  and  equivalence  of  student  programs.  There  is  also  a 
description  of  a  method  for  determining  program  difficulty. 

G  ANNO  N75a 

Gannon,  J.D.  and  Horning,  J.J.;  The  Impact  of  Language  Design  on 
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the  Production  of  Reliable  Software;  in 
Reliable  Software:  Language  Design,  Dyadic 
Complementary  Semantics;  Technical  Report 
Research  Group,  University  of  Toronto  (Januar 


Three  Approaches  to 
Specification,  and 
44,  Computer  Systems 
y  1975) . 


Gannon  and  Horning  investigate  the  effects  of  langua 
decisions  on  the  error  rate  of  programmers.  They  first 
small  programming  language  and  identify  nine  (nearly) 
error-prone  constructs.  They  redesign  these  constr 
accordance  with  intuition  and  human  learning  princi 
incorporate  the  modified  constructs  in  a  new  dialect 
language.  In  a  carefully  controlled  experiment,  progra 
found  to  make  significantly  fewer  (and  less  severe  in 
persistence)  errors  in  the  modified  dialect  than  in  the 
language.  This  paper  is  excellent,  and  the  results 
immediate  practical  value. 


ge  design 
select  a 
unrelated 
uc  ts  in 
pies,  and 
of  the 
mmers  are 
terms  of 
original 
are  of 


GANNON75b 

Gannon,  J.D.,  and  Horning,  J.J.;  The  Impact  of  Language  Design  on 
the  Production  of  Reliable  Software;  Proceedings  International 
Conference  on  Reliable  Software,  SIGPLAN  Notices  10,6  (June  1975) 

pp. 10-22. 

This  paper  examines  some  of  the  features  of  language  design  that 
may  increase  the  reliability  of  programs.  Like  other  literature 
on  the  subject,  a  list  of  intuitively  selected  design  features 
with  descriptions  of  each  is  provided.  Unlike  most  other 
literature,  empirical  evidence  is  given  to  support  the  use  of  some 
of  the  features  in  language  design.  The  evidence  is  from  an 
experiment  by  Gannon  that  measures  the  effect  of  nine  language 
design  decisions  on  the  frequency  and  severity  of  programming 
errors.  An  analysis  of  the  results  of  each  design  decision  is 
included. 


GANN0N75c 

Gannon,  J.D.;  Language  and  Compiler  Design  to  Reduce  the  Effect  of 
Errors;  Software  Engineering  Education  Proceedings,  IBM  Scientific 
Symposium,  Montebello,  Quebec  (May  1975)  pp. 76-91. 

While  some  language  features  may  lead  to  more  efficient  programs. 


their  value  is 
incorrectly  or  in 

questionable 
"clever"  ways. 

if  they  are 

frequently 

used 

A  small  language 

was  tested 

for  error- prone 

constructs. 

Nine 

constructs  were  identified  and  redesigned  in  an  attempt  to  make  a 
less  error-prone  language.  The  original  and  redesigned  languages 
were  used  in  an  experiment  by  two  groups  of  programmers  who  had 
had  experience  with  other  programming  languages.  The  results 
indicated  that  programs  written  in  the  redesigned  language  were 
less  subject  to  errors. 

Three  design  principles  were  considered  to  be  significant  in 
redesigning  the  language.  The  language  design  should  be  uniform 
so  that  the  language  is  easier  to  learn.  Redundancy  should  be 
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provided  for  compile- ti me  error  detection.  Programmers' 
experiences  with  natural  language,  mathematics,  and  other 
programming  languages  should  guide  language  design. 


GEE  HART7  6 

Gerhart,  S.L.,  and  Yelowitz,  I.;  Observations  of  Fallability  In 
Applications  of  Modern  Programming  Methodologies;  IEEE 
Transactions  on  Software  Engineering  SE-2,3  (September  1976) 
pp. 195-207. 


This  paper  examines  what  success  modern  programming  methodologies 
have  actually  had  in  the  reduction  of  errors  in  programs.  The 
authors  contend  that  while  techniques  such  as  Formal 
Specification,  Program  Structuring,  Systematic  Construction,  and 
Program  Proving  may  and  in  fact  do  reduce  errors,  we  are  not  yet 
at  the  point  where  program  testing  is  not  required.  Several 
programs  published  in  recent  papers  are  supplied  as  examples  to 
support  this  viewpoint.  All  of  these  examples  were  constructed 
using  software  engineering  techniques  including  program 
verification  proofs  and  they  still  contained  errors.  This  is  a 
good  paper  for  it  shows  that  for  all  the  software  engineering 
efforts  of  late,  program  errors  are  still  with  us. 


GERMAN75 

German,  S.M.,  and  Wegbreit,  B.;  A  Synthesizer  of  Inductive 
Assertions;  IEEE  Transactions  on  Software  Engineering  SE-1,1 
(March  1975)  pp. 68-75. 

The  authors  discuss  a  program  which  uses  several  methods  for  the 
generation  of  intermediate  assertions  in  proving  program 
correctnesss.  The  techniques  also  enable  completion  of  incomplete 
assertions  supplied  by  the  programmer.  The  application  of  these 
techniques  to  several  examples  is  shown,  although  the  techniques 
dc  not  work  completely  on  all  the  examples. 


GILB76 

Gilb,  T. ;  A  Skeptical  View  of  Structured  Programming  and  Some 
Alternatives;  Computers  and  People  25,5  (May  1976)  pp.2C-23,  and 

25,6  (June  1976)  pp. 20-22. 

While  not  discrediting  structured  programming,  the  author  would 
like  to  see  reasonable  scientific  evidence  that  structured 
programming  is  better  than  other  programming  techniques  The 
following  metric  is  suggested  for  measurement:  "The  probability 
that  a  (defined)  program  source  reader  can  correctly  understand 
the  logic  within  a  given  time". 

A  number  of  alternative  and  supplementary  techniques  to  structured 
programming  are  described  briefly.  These  techniques  are  program 
comments,  modularization,  maintainability  metrics,  debugging 
metrics,  dual  coding,  automated  test  path  analysis,  process 
inspections,  and  data  redundancy. 
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GC0D75 

Good,  D.I.,  London,  R.L.,  and  Bledsoe,  W.W.;  An  Interactive 
Program  Verification  System;  IEEE  Transactions  on  Software 
Engineering  SE-1,1  (March  1975)  pp. 59-67. 

A  description  of  an  interactive  system  for  the  proof  of  program 
correctness.  The  three  phases  of  the  system  -  verification 
condition  generation,  algebraic  and  logical  manipulation,  and 
theorem  proving  are  all  described  in  reference  to  a  non-trivial 
sort  procedure  example.  This  paper  presupposes  a  familarity  with 
basic  notions  of  proof  of  correctness. 


GOODE  NOUGH75 

Goodenough,  J.B.,  and  Gerhart,  S. L. ;  Toward  a  Theory  of  Test  Data 
Selection;  IEEE  Transactions  on  Software  Engineering  SE-1,2  (June 
1975)  pp. 156-173. 

An  analysis  of  the  role  of  using  program  test  data  in  the  proof  of 
correctness.  The  authors  examine  the  properties  of  a  selector,  a 
mechanism  for  the  selection  of  a  test  data  set  from  the  domain  of 
possible  program  inputs,  and  point  out  what  this  selector  must  be 
able  to  guarantee  about  the  test  data  set  to  ensure  program 
correctness . 


GOULD  73 

Gould,  T.D.;  Some  Psychological  Evidence  on  How  People  Debug 
Computer  Programs;  EC  4542  (7B20208) ,  IBM  Thomas  J.  Watson 
Research  Center,  Yorktown  Heights,  New  York  (September  1973)  pp.1- 
53. 

This  paper  reports  the  results  of  a  study  on  how  experienced 
Fortran  programmers  from  the  IBM  Research  Center  debugged  Fortran 
programs  which  contained  single-line  errors.  Two  motivations  for 
the  experiment  were  to  analyze  and  report  on  various  debugging 
strategies,  and  to  compare  the  way  programmers  debugged  when 
allowed  to  use  interactive  debugging  tools.  Results  included 
otservations  that 

1)  "Highly  motivated"  subjects  could  debug  the  programs  as 
efficiently  when  just  examined  the  listing  as  they  could  when  they 
had  access  to  what  had  been  considered  aids; 

2)  Subjects  found  meaningful  mnemonics  useful  in  debugging. 

3)  Bugs  in  assignment  statements  were  the  most  difficult  to 
debug,  primaril  because  subjects  had  to  have  a  more  thorough 
understanding  of  the  substance  of  the  program. 

Studies  of  this  nature  are  open  to  a  great  number  of  criticisms. 
One  criticism  concerns  the  conclusion  that  programmers  didn't  seem 
to  use  what  were  considered  debugging  aids;  the  reasons  for  not 
using  the  interactive  system  provided  were  too  numerous  (lack  of 
programmer  familiarity  and  poor  design  of  the  interactive  system, 
to  name  two)  to  support  such  conclusions  very  strongly.  On  the 
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whole,  however,  the  paper  seems  useful  in  providing  a  documented 
study  cf  the  programming  process,  and  shedding  some  light  on  the 
debugging  task, 

G  RAHA  M73a  CR25,424 
Graham,  R.M.,  Clancy  Jr.,  G.J.,  and  Devaney,  D.B.  ;  A  Software 
Design  and  Evaluation  System;  CACM  16,2  (February  1973)  pp.110- 
116. 

The  DES  system  is  an  operating  system  writing  system,  implemented 
in  a  superset  of  PL/1.  Procedures,  data  items  and  hardware 
characteristics  are  maintained  in  a  data  set  that  aids  in 
simulating  the  performance  of  incompletely  written  subsystems. 
Each  component  can  be  evaluated  to  produce  a  graph  representation 
of  the  procedure,  information  on  external  references,  resource 
usage  and  interface  and  constraint  violations.  The  methodology 
produces  a  probabilistically  collapsed  graph  of  the  original 
system  which  is  input  to  a  general  purpose  simulator. 
Unfortunately,  asynchronous  behavior  is  not  adeguately  modelled. 
Essentially,  this  is  still  a  'toy*  system  since  its  authors  admit 
that  no  large  system  like  the  Multics  system  could  be  successfully 
modelled. 


GRAHA  M73b 

Graham,  S.L.,  and  Rhodes,  S.P.;  Practical  Syntactic  Error  Recovery 
in  Compilers;  ACM  Symposium  on  Principles  of  Programming 
Languages,  Boston,  Mass.  (October  1973)  pp. 52-58. 

The  article  proposes  a  method  of  error  detection  and  recovery  to 
"maximize  the  numbers  of  errors  detected"  and  "minimize  the  number 
of  times  it  reports  an  error  when  there  is  none."  The  aim  of  the 
system  is  thus  to  minimize  the  number  of  runs  needed  to  debug  a 
program  with  syntax  errors.  The  method  is  composed  of  two  parts:  a 
condensation  phase  where  the  system  tries  to  locally  recover  from 
the  error  and  continue  parsing,  and  a  correction  phase  which 
attempts  to  correct  the  error. 


GRIFFITH7  2 

Griffith,  P.F.,  and  Henry,  R.M.;  An  Investigatory  Study  into  Human 
Problem  Solving  Capabilities  as  They  Relate  to  Programmer 
Efficiency;  SIGCPR  Bulletin  3,3  (1972)  pp. 10-14. 

This  paper  is  detailed  description  of  a  research  study 
investigating  programer  efficiency  as  it  relates  to  maintaining 
varying  numbers  of  COBOL  data  processing  programs.  The  results 
showed  that  greater  programmer  efficiency  occurred  in  solving  3 
problems  in  parallel  than  solving  3  problems  sequentially.  The 
sample  size  was  18  subjects.  Hence  the  results  are  at  best 
marginally  significant.  These  results  seem  contrary  to  other 
results  noted  in  'current  literature',  but  did  generate  much 
enthusiasm  in  the  subjects  doing  the  parallel  processing. 
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GRIES74 

Gries,  D. ;  On  Structured  Programming  -  A  Reply  to  Smoliar;  CACM 
17,11  (November  1974)  pp. 655-657. 

A  well  reasoned  well  stated  attempt  to  explain  the  connotations  of 
the  term  "structured  programming." 

GUNDERMAN73 

Gunderman,  R.E.;  A  Glimpse  into  Program  Maintenance;  Datamation 
19,6  (June  1973)  pp. 99-101. 

Program  maintenance  is  described  as  "a  large  and  continually 
growing  area  of  activity  which  is  taking  its  toll  in  time,  money, 
manpower,  computer  use,  profits,  etc."  These  problems  are 
attributed  to  maintenance  having  been  largely  ignored,  or  viewed 
as  an  activity  for  second  class  programmers  who  are  not  yet 
capable  of  original  program  development.  The  lack  of  published 
literature  and  research  on  debugging  is  a  problem.  A  typical 
system  problem  and  the  implications  of  fixing  it  are  described  and 
the  organization  of  an  effective  "maintenance  facility"  is 
discussed . 


GUTTAG75 

Guttag,  J.V.;  Dyadic  Specification  and  its  Impact  on  Reliability; 
in  Three  Approaches  to  Reliable  Software:  Language  Design,  Dyadic 
Specification,  and  Complementary  Semantics;  Technical  Report  44, 
Computer  Systems  Research  Group,  University  of  Toronto  (January 
1975). 

The  specification  of  data  types  is  normally  carried  out  in  either 
a  procedural  or  a  descriptive  manner.  Each  technique  has  its 
advantages  and  its  limitations.  Guttag  presents  an  algebraic 
specification  technique  combining  the  best  features  of  the 
procedural  and  descriptive  approaches.  He  discusses  its 
implications  for  structured  design  and  specification,  correctness 
proofs,  and  program  testing.  His  eventual  goal  is  an  interactive 
specification  system  that  will  recognize  (and  help  construct)  a 
set  of  axioms  sufficient  to  fully  describe  a  data  type  in  an 
i mple mentation -in depen dent  manner. 


HABER  MANN73 

Habermann,  A.N.;  Integrated  Design;  SIGPLAN  Notices  8,9  (September 
1973)  pp. 64-66. 

An  argument  is  given  for  the  integration  of  the  design,  analysis, 
and  implementation  efforts  of  a  programming  system  into  one 
production  effort  in  which  documentation  is  a  primary  issue.  Also 
it  is  argued  that  the  design  concepts  should  not  be  presented  in 
the  language  chosen  for  implementation  as  it  may  dominate  the 
project. 
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HAGUE  76 

Hague,  S.J.,  and  Ford,  B. ;  Portability  -  Prediction  and 
Correction;  Software  -  Practice  and  Experience  6,1  ( January-March 
1 S76)  . 

The  usual  approach  to  software  portability  is  to  first  restrict 
one's  self  to  an  almost  machine-independent  subset  and  then  either 
marking  areas  that  might  need  change  cr  forming  a  composite  file 
from  which  records  appropriate  to  a  particular  machine  are 
extracted.  This  the  authors  refer  to  as  the  predictive  approach. 
They  then  proceed  to  describe  the  NAG  Master  Library  File  System 
where  a  correction  phase  is  added  to  the  project.  That  is,  after 
an  implementation  has  been  effected,  it  is  compared  with  the 
library  version  and,  if  different,  recorded. 


HALSTEAD72 

Halstead,  M.H.;  Natural  Laws  Controlling  Algorithm  Structure?; 
SIGPLAN  Notices  7,2  (February  1972)  pp. 22-30. 

The  authcr  proposes  that  algorithms  obey  natural  laws,  which  are 
based  on  two  independent  properties,  the  number  of  distinct 
operators  and  the  number  of  distinct  operands.  A  certain  function 
of  these  properties,  called  the  Internal  Quality  of  an  algorithm, 
is  said  to  be  independent  of  the  language  in  which  the  given 
algorithm  is  expressed.  The  statistics  presented  are,  to  say  the 
least,  unconvincing. 


HALSTEAD7  3 

Halstead,  M.H.;  Language  Selection  for  Applications;  Proceedings 
of  the  SJCC  42  (June  1973)  pp. 211-214. 

The  authcr  outlines  guidelines  for  selecting  a  new  language  for  a 
given  application.  Four  important  considerations  which  should  be 
recognized  when  making  such  decisions  are:  1.  How  a  programmer 
spends  his  time  2.  Differences  in  local  and  global  inefficiency  3. 
The  role  of  the  expansion  ratio  4.  Variance  in  programmer 
productiv ity . 

While  describing  these  considerations,  the  author  points  out  costs 
which  vary  over  the  language  used. 

Finally,  the  author  concludes  by  mentioning  those  critical  factors 
which  should  be  weighed  in  a  management  decision  for  an  alternate 
high  level  language.  These  involve:  whether  the  higher  level 
language  (higher  than  what  is  currently  in  use)  is  high  enough  for 
a  sufficiently  large  majority  of  program  applications,  that  data 
collected  on  small  programs  is  not  representative  of  the  crucial 
programs  (i.e.,  the  large  ones)  and  that  costs  of  conversion  from 
the  new  language  to  another  computer  are  a  very  important 
consideration . 
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HAMMER  7  6 

Hammer,  M„;  Data  Abstractions  for  Data  Bases;  Proceedings 
Conference  on  Data,  SIGPLAN  Notices  Special  Issue  (1976)  pp. 58-59. 


The  similarities  between  the  principle  of  data  abstraction  and  the 
concept  of  data  independence  in  data  base  management  are 
presented.  They  each  share  the  same  goal  with  particular 
relevance  in  the  Relational  Schema.  Basic  discrepancies  of  the  two 
concepts  with  regard  to  implementation  of  data  abstractions  in 
data  base  management  is  expressed. 

HANEY72  CR25,504 
Haney,  F.M.;  Module  Connection  Analysis  -  A  Tool  for  Scheduling 
Software  Debugging  Activities;  Proceedings  of  the  FJCC  41  (1972) 
pp. 173-179. 


Presents  a  method  for 
make  changes  to  a  large 
and  integration  of  such  a  system, 
modules,  the  method  examines  an 
probabilities,  the  (i,j)th  element 
change  in  the  ith  module  will  require 
Knowing  this  matrix  and  knowing 


estimating  the  amount  of  work  necessary  to 
system,  or  to  complete  the  final  testing 

For  a  system  composed  of  M 
n  matrix  of  estimated 
being  the  probability  that  a 
a  change  in  the  jth  module, 
the  number  of  initial  ("first 


order")  changes  (usually  corrections  of  bugs)  that  a  system 
requires,  one  can  then  easily  compute  how  rapidly  the  system 
converges  to  one  where  the  desired  changes  have  been  made  and  no 
undesired  changes  introduced,  and  whether  this  process  can  be 
expected  to  converge  at  all.  The  method  is  applied  in  evaluating 
a  strategy  for  releasing  new  versions  of  a  specific  example 
syste  m . 


HARKER75 

Harker,  W.C.;  Systems  Programmer  Education  Deficiencies;  Software 
Engineering  Education  Proceedings,  IBM  Scientific  Symposium, 
Montebello,  Quebec  (May  1975)  pp. 98-103. 

The  author  presents  results  of  a  survey  of  computer  science 
graduates  working  as  system  programmers  in  a  company.  He 
discusses  the  need  to  present  courses  that  have  greater  relevance 
to  industry.  Such  issues  as  project  management,  programming 
techniques,  computer  system  design  are  found  to  be  lacking  in  the 
student's  experience.  Furthermore,  the  author  suggests  a 
reduction  in  degree  of  specialization  prevalent  in  university 
studies,  and  emphasizes  a  greater  breadth  requirement.  Directions 
for  future  modifications  in  university  curricula  are  presented. 
These  changes  involve  reduction  in  the  level  of  specialization  in 
particular  courses,  emphasis  on  people-to-people  interaction, 
understanding  of  business,  and  methodical  approach  to  system 
design.  the  author  also  suggests  that  students  receive  greater 
exposure  to  work  environments  during  their  studies. 


HEIDORN76 

Heidorn,  G.E.;  Automatic  Programming  through  Natural  Language 


-38 


Current  Articles 


Dialogue:  A  Survey;  IBM  Journal  of  Research  and  Development  20,4 
(July  1976)  pp. 302-313. 

This  is  a  survey  of  four  projects  in  the  area:  Naval  Postgraduate 
School,  Information  Systems  Institute  at  DSC,  MIT,  and  IBM.  All 
four  projects  are  based  on  the  interaction  with  a  non  Computer 
Sophisticated  user  on  the  nature  of  the  problem  to  either  produce 
a  program  for  a  general  or  to  customize  an  application  to  the 
u eer '  s  needs. 

Points  of  note  are:  only  two  (NPGS,ISI)  have  produced  a  working 
prototype,  the  NPGS  project  has  been  abandoned,  and  the  ISI 
program  took  1  CPU  hour  on  a  PDP-10  to  produce  a  small  program. 
It  would  seem  that  the  aspirations  of  automatic  programming  are 
not  yet  realizable. 


HENDERSON72 

Henderson,  P.,  and  Snowdon,  R.;  An  Experiment  in  Structured 
Programming;  BIT  12  (1972)  pp. 38-53. 

An  example  of  top-down  development  of  a  program  is  given.  (The 
example  is  a  program  to  process  telegrams).  Although  carefully 
constructed  and  correct  in  appearance,  the  program  contains  an 
error.  The  process  of  using  the  structure  to  locate  and  correct 
the  error  (as  opposed  to  patching  the  final  program)  is  examined 
to  see  if  error  location  is  improved  by  the  structuring.  In 
addition,  some  pitfalls  of  structured  programming  are  described. 
This  paper  is  a  good  antidote  to  unalloyed  euphoria  about 
structured  programming. 


HENRI C  KSE  N7  2 

Henricksen,  J.O.,  and  Merwin,  R.E.; 
Efficiency  in  Real-Time  Software  Systems; 
40  (1972)  pp. 155-161. 


CR2  3,80  5 
Programming  Language 
Proceedings  of  the  SJCC 


This  paper  attempts  to  examine  how  the  trade-offs  between 
efficiency  of  generated  code,  space  requirements,  run  time (speed) 
and  programmer-written  statements  are  affected  by  the  choice  of  a 
programming  language.  This  paper  reports  the  results  of 
i nplementing  a  number  of  well-defined  algorithms  in  each  of 
several  languages,  on  a  number  of  different  machines.  The  authors 
draw  seemingly  warranted  conclusions. 


HETZEL73 

Hetzel,  W.C.;  Princles  of  Computer  Program  Testing;  in  Hetzel, 
W.C. (ed.).  Program  Test  Methods ;  Prentice-Hall  (1973)  pp. 17-28. 

The  author's  stated  intention  is  to  give  a  general  impression  of 
testing  activity  rather  than  a  complete  understanding.  The  paper 
is  simply  a  survey  of  the  literature  on  program  testing.  While 
most  of  the  literature  reviewed  is  now  dated,  the  paper  does 
provide  an  historical  prespective  on  the  subject  of  testing.  It 
also  provides  a  useful  framework  for  any  discussion  of  program 
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testing.  Hetzel  identifies  and  describes  the  following  seven 
testing  principles:  segmentation,  design  for  testability, 
simulation,  sampling,  logical  reduction,  standardization, 
automation.  He  concludes  that  automatic  examination  will  be  the 
most  important  testing  principle  in  the  future. 


HILL7  2 

Hill,  I.D.;  Wouldn't  it  be  nice  if  we  could  write  computer 
programs  in  ordinary  English  -  or  would  it?;  The  Computer  Bulletin 
16,6  (June  1972)  pp. 306-312 


A  somewhat  weak  attempt  to  argue  that  "ordinary  English"  could 
never  be  used  as  a  programming  language,  since  its  intricacies  are 
beyond  our  ability  to  translate  -  "can  anyone,  today,  even  begin 
to  think  how  to  write  [a  program  to  understand  ordinary  English]?" 
Although  the  author  provides  an  amusing  demonstration,  with  many 
examples,  of  the  (obvious)  fact  that  English  abounds  with 
ambiguities,  he  seems  not  to  be  aware  that  there  is  such  a 
discipline  as  Artificial  Intelligence,  which  in  fact  concerns 
itself  (realistically)  with  natural  language  understanding 
systems.  Less  shakily,  he  argues  that  even  if  we  had  such  a 
programming  system,  we  would  lose  much  of  the  unambiguous 
precision  which  we  have  grown  to  expect  from  a  computer  -  and  he 
proposes  that  a  more  useful  development  would  be  the  introduction 
of  a  precise,  algorithmic  language  for  human  communication  (of 
instructions) . 


HOARE72a 

Hoare,  C.A.R.;  Notes  on  Data  Structuring;  in  Dahl,  O.J.,  Dijkstra, 
E.W.  ,  and  Hoare,  C.A.R.;  Structured  Programming;  Academic  Press, 
New  York  (1972)  pp. 83-174. 

The  author  motivates  the  monograph  by  presenting  the  notion  of 
abstraction,  illustrated  by  real-world  and  programming  language 
examples.  Within  this  setting  the  notion  of  a  type  is  given,  with 
special  attention  devoted  to  the  operations  defined  for  values  of 
a  type.  A  detailed  description  of  structuring  operations  on  types 
is  given,  emphasizing  the  meaning  of  the  structures,  and 
manipulations  and  representations  of  values  of  the  structures.  An 
example  illustrates  the  use  of  the  structuring  operations  to 
refine  abstract  types.  Finally,  an  axiomatization  of  the  types  is 
presented . 


HO ARE72b 
Hoare ,  C 

C. A. R. 

A  cadem ic 


CR25,  944 

. A.R.;  Towards  a  Theory  of  Parallel  Programming;  in  Hoare, 
and  Perrott,  R.H. (eds.).  Operating  Systems  Techniques, 
Press,  N.Y.  (1972)  pp. 61-71. 


This  paper  begins  with  a  brief  discussion  of  objectives  to  be  met 
in  designing  a  parallel  processing  feature  for  high^'le  vel 
language:  compile-time  checks  to  avoid  time-dependent  errors, 

generation  of  efficient  code,  and  constructs  which  are  both 
conceptually  simple  and  widely  applicable. 
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Constructs  are  proposed  for  defining  parallel  processes,  defining 
resources,  and  using  them  for  interprocess  communication.  These 
constructs  appear  to  satisfy  the  stated  objectives  quite  well, 
although  the  notation  for  the  first  seems  rather  difficult  to  read 
and  prone  to  coding  errors;  the  semantics  of  the  third  allow  a 
definite  possibility  for  "b usy- waiting , M  something  which  might  be 
avoided  by  a  more  sophisticated  enqueuing  of  blocked  processes  on 
conditions  rather  than  on  simple  resource  availability. 

Two  other  useful  concepts  are  introduced:  the  capability  of 
partitioning  arrays  to  allow  simultaneous  access  by  more  than  one 
process,  and  the  ability  to  define  arrays  of  resources. 


HO ARE  72c 

Hoare,  C.A.R.;  Proof  of  Correctness  of  Data  Representation;  Acta 
Informatica-I,  Spr in ger-Ver lag  (1972)  pp. 271-281. 

Hoare  proposes  that  one  should  develop  algorithms  with  abstract 
data  concepts,  and  choose  a  representation  for  the  data  after  the 
design  is  finished.  In  this  paper  he  discusses  the  problem  of 
proving  that  the  concrete  representation  chosen  actually  performs 
to  the  requirements  of  the  abstract  concept.  He  uses  the 
methodology  of  SIMULA  data  constructs  and  provides  a  small  example 
proof. 


HOAR  E73a 

Hoare,  C.A.R.;  Hints  on  Programming  Language  Design;  Technical 
Report  STAN-CS -73-403 ,  Computer  Science  Department,  Stanford 
Universit  pp.1-30. 

This  highly  readable  and  frequently  entertaining  article  begins 
with  the  observation  that  "a  programming  language  is  a  tool  which 
should  assist  the  programmer  in  the  most  difficult  aspects  of  his 
art,  namely  program  design,  documentation  and  debugging." 

In  this  context,  Hoare  reflects  on  numerous  language  and  compiler 
features.  He  argues  that  a  good  language  should  encourage  simple 
and  readable  programs,  and  have  a  fast  compiler  which  can  produce 
secure  and  efficient  code.  He  suggests  that  a  good  many  of  the 
newer  languages  may  actually  make  the  programmer's  task  more 
dif f icult . 

One  is  reminded  that  an  extremely  important  part  of  the  design 
process  is  the  decision  of  what  to  omit,  an  aspect  which  appears 
rarely  to  have  received  adequate  attention. 

HOAR  E73b 

Hoare,  C.A.R.;  Recursive  Data  Structures;  Stanford  University, 
Computer  Science  Dept.,  STAN-CS-73-400  (October  1973)  pp.1-32. 

The  author  proposes  an  extension  to  programming  languages  to  allow 
data  structures  to  be  defined  by  recursion.  The  formalism  is  to 
define  a  "type"  in  terms  of  a  recursive  application  of 
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"generators"  over  a  type  list.  Manipulation  of  these  structures 
is  confined  to  further  applications  of  the  generators  on  instances 
of  the  defined  type. 

The  claiii  is  made  that  such  a  schema  would  eliminate  the  problems 
associated  with  the  PL/1  or  Algol68  pointer  type.  The  pointer 
type  is  cited  as  the  data  structures  equivalent  of  the  "go  to"  in 
control  structures. 

The  author  goes  on  to  define  his  new  construct  in  an  axiomatic 
fashion  and  to  suggest  implementation  methods. 


HCARE73C 

Hoare,  C.A.R.,  and  Wirth,  N. ;  An  Axiomatic  Definition  of  the 
Programming  Language  PASCAL;  Acta  Informatica  2  (1973)  pp. 335-355. 

An  attempt  to  describe  formally  the  semantics  of  the  language 
PASCAL.  The  basis  for  this  is  the  approach  expounded  in  "An 
Axiomatic  Basis  for  Computer  Programming"  [HOARE69].  The 
definition  is  guite  useful  but  it  is  incomplete;  some  language 
features  were  left  out  and  some  restrictions  were  made.  These 
omissions  seem  to  be  due  to  complexity  and  point  to  parts  of  the 
language  worth  considering.  The  omissions  include;  real 
arithmetic,  GO  TOs,  ALPHA-type.  The  following  features  are 
imperfectly  described;  classes,  procedures  and  functions  with 
regard  to  global  variables.  This  document  does  not  replace  the 
original  defining  report,  it  only  supplements  it. 


HOARE74 

Hoare,  C.A.R.;  Monitors:  an  Operating  System  Structuring  Concepts; 
C  ACM  17,10  (October  1974)  pp.  549-557. 

This  paper  presents  a  very  good  description  of  how  monitors  may  be 
defined  and  applied  to  a  number  of  practical  problems  in  operating 
systems.  Various  details  are  discussed,  such  as  the  peculiar 
nature  of  the  "condition  variable,"  proof  rules  which  may  be 
stated  for  monitors,  and  how  a  monitor  may  be  implemented  using 
semaphores.  (This  last  is  rather  confusing,  since  not  all  the 
semaphore  operations  are  stated  explicitly). 

The  most  valuable  aspect  of  the  paper  is  the  extensive  set  of 
examples,  which  both  elucidate  the  properties  of  monitors,  and 
give  a  good  idea  of  the  wide  variety  of  problems  to  which  they 
might  be  applied. 


HCARE75 

Hoare,  C.A.R.;  Data  Reliability;  Proceedings  International 
Conference  on  Reliable  Software,  SIGPLAN  Notices  10,6  (June  1975) 
pp. 528- 533 . 

The  author  contends  that  the  problems  of  data  reliability  are  even 
more  severe  than  the  already  notorious  ones  of  program 
reliability.  He  cites  several  reasons  for  this:  (a)  Incorrect 
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program  runs  can  place  propogating  bugs  in  a  data  base, 
(b)  hardware  errors  can  severely  damage  data,  and  (c)  problems  of 
user  confidence  are  more  severe.  To  alleviate  this  problem  he 
proposes:  data  structuring  with  concepts  such  as  type,  top  down 

design  cf  data  representation,  and  elimination  of  references  and 
pointers  (eguating  them  to  "goto's"  in  program  languages). 


HCILANC73 

Holland,  J.G. ;  Acceptance  Testing  for  Applications  Programs;  in 
Hetzel,  W.C.  (ed.).  Program  Test  Methods ;  Prentice-Hall  (  1973) 
pp.  26  3-27  4. 

While  serious  consideration  has  been  given  to  the  detailed  testing 
of  programs  by  program  designers,  little  thought  has  been  given  to 
acceptance  testing.  This  paper  is  an  attept  to  provoke  discussion 
in  the  area  of  acceptance  testing. 

Most  of  the  paper  is  devoted  to  a  comparison  of  the  reguirememts 
of  the  two  types  of  testing.  By  highlighting  the  differences,  the 
author  hopes  to  stimulate  discussion  about  possible  models  for 
acceptance  testing  that  will  differ  from  the  current  models  for 
program  validation.  The  author  recommends  a  statistical  model 
(empirical)  rather  than  the  analytical  type.  He  suggests  Good's 
analytical  model  (a-process)  may  be  adapted  for  use  in  the 
empirical  model. 


H  CLT7  3a 

Holt,  R.C.;  Teaching  the  Fatal  Disease  (or)  Introductory  Computer 
Programming  Using  PL/I;  SIGPLAN  Notices  8,5  (May  1973)  pp.8-23. 

The  author  makes  plentiful  use  of  humour  and  examples  to  support 
his  dual  claim  that  PL/I  is  a  good  language  to  use  in  teaching 
introductory  programming  (or  implementing  computer  systems)  but 
that  successful  use  of  PL/I  depends  upon  restricting  oneself  to  a 
small  subset  of  the  language.  He  claims  that  to  successfully  teach 
(or  use)  structured  programming  techniques,  one  must  write 
programs  in  a  small  language  that  can  be  completely  mastered.  The 
rules  he  suggests  for  subsetting  the  language  restrict  control 
constructs  to  a  structured  set,  and  restrict  data  types  to  avoid 
the  messy  conversion  and  precision  rules. 


H  CLT7  3b 

Holt,  R.C.  and  Wortman,  D.B.;  Structured  Subsets  of  the  PL/I 
Language;  Technical  Report  27,  Computer  Systems  Research  Group, 
University  of  Toronto  (October  1973)  pp.1-27. 

This  paper  presents  a  sequence  of  subsets  of  the  PL/I  language 
developed  by  the  authors  for  the  purpose  of  teaching  introductory 
programming.  The  subsets  are  based  on  the  thoughts  given  in 
"Teaching  the  Fatal  Disease"  on  taming  PL/I  for  teaching 
structured  programming.  A  description  of  the  University  of 
Toronto's  SP/k  compiler  which  enforces  use  of  the  subsets  is 
given. 
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HOLT75 

Holt,  R.C.;  Structure  of  Computer  Programs:  a  Survey;  Proceedings 
of  the  IEEE  63,6  (June  1975)  pp. 879-893. 

The  author  examines  the  reasons  and  methods  for  dividing  "large" 
programs,  concentrating  on  overall  external  program  structure, 
rather  than  internal  control  structures.  He  describes  the  focus 
of  the  paper  as  "The  Organization  of  Software",  and  perhaps  this 
would  have  been  a  more  appropriate  title. 

The  author  states  that  program  division  is  due  to  both  hardware 
constraints  (limited  memory,  excessive  running  time,  etc.)  and 
human  constraints  (delegation  of  programming,  better 
under standability,  etc.).  The  method  of  division  -  functional 
decomposition  -  is  seen  to  best  follow  a  top-down  approach.  He 
then  considers  "Mechanisms  for  Program  Composition"  -  that  is, 
tools  for  combining  smaller  pieces  into  a  complete  program  such  as 
parameter  passing,  shared  data  and  synchronous  interactions.  Some 
of  this  portion  of  the  discussion  is  at  the  operating  system 
level,  with  discussions  of  program  linkage,  traps  and  interrupts, 
and  may  prove  too  complex  for  the  "average"  programmer.  This 
portion  of  the  article  also  considers  coroutines  and  discusses 
possible  interactions  using  semaphores  and  mailboxes. 

Finally,  he  considers  program  "folding"  due  to  memory  limitations, 
describing  three  methods  -  overlays,  segmentation  and  paging  -  and 
the  effects  on  programs  of  each. 


HCPKI NS72 

Hopkins,  M.E.;  The  GOTO  Controversy:  A  Case  for  the  GOTO;  SIGPLAN 
Notices  7,11  (November  1972)  pp. 59-62. 

Because  the  GOTO  Controversy  seems  totally  dead  (at  least  in  an 
university  environment)  as  a  result  of  overwhelming  opposition  to 
the  construct,  this  paper  makes  good  reading.  It  points  out  many 
reasons  for  retaining  the  GOTO  in  modern  programming  languages. 
The  irajor  emphasis  is  on  the  fact  that  programming  without  GOTO's 
does  not  imply  good  "structured"  programming,  neither  does  the 
presence  of  the  GOTO  imply  badly  structured  programming,  in  fact, 
many  people  in  trying  to  eliminate  the  construct,  lose  sight  of 
the  ultimate  goals. 


HORNI NG7  4a 

Horning  J.J.;  What  the  Compiler  should  tell  the  User,  in  "Compiler 
Construction:  An  Advanced  Course,"  F.L.  Bauer,  Editor,  Springer- 
Verlag,  Berlin  (1974)  pp.  525-548. 

An  excellent  article  which  should  be  read  by  anyone  who  is 
starting  to  write  a  compiler.  It  describes  the  needs  of  the 
programmer  who  will  be  using  the  compiler,  emphasizing  the  fact 
that  all  programs  have  errors  in  them  when  they  are  first  written. 
The  fast  development  of  correct  programs  requires  an  intelligent 
solution  to  the  problems  of  error  detection,  diagnosis,  and 
documentation  by  the  compiler  so  that  the  user  may  easily  discover 
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his  mistakes.  Output  should  be  in  language  understandable  by  the 
user  (who  should  not  be  expected  to  knew  compiler  jargon) .  In 
fact,  for  anyone  writing  a  program  to  be  used  by  someone  else, 
this  article  could  be  used  as  a  guide  to  what  should  appear  in  the 
program  output.  Perhaps  a  better  title  would  be  "What  the  Program 
Should  Tell  the  User." 


H0RNING74b 

Horning,  J.J.,  Lauer,  H.C.,  Melliar-Smith ,  P.M.,  and  Randell,  B. ; 
A  Program  Structure  for  Error  Detection  And  Recovery;  University 
of  Newcastle  Upon  Tyne,  Computing  Laboratory,  Technical  Report  59 
(April  1974)  pp. 1-16. 

This  paper  presents  a  structured  formalism  and  an  associated 
recovery  machine  for  dealing  with  hardware  and  software  errors. 

On  the  premise  that  error  detection  and  recovery  is  useful,  the 
authors  develop  the  "Recovery  Block"  construct  which  includes  the 
intended  operation,  a  testing  mechanism,  and  an  associated  set  of 
"alternative  blocks. "  "Recovery  blocks"  can  be  nested  (and 
structured) .  This  suggests  a  stack-like  mechanism  be  used  to  keep 
track  of  variables  (and  pathways)  for  recovery.  The  authors 
present  the  "recursive  cache"  as  a  reasonable  implementation  of 
such  a  mechanism.  The  "recursive  cache"  only  keeps  track  of 
changed  (written)  variables.  Pecovery  proceeds  by  restoring  all 
changed  "recovery  block"  variables  and  entering  an  appropriate 
"alternative  block." 

A  more  complex  form  of  this  scheme,  "recoverable  procedures,"  is 
proposed  for  recovery  from  the  more  typical  systems  environment, 
involving  operations  other  than  assignment.  The  authors  indicate 
some  ongoing  implementation  efforts.  (Perhaps  the  significance  of 
error  recovery  design  in  software  systems  is  understated.) 


HCRNING76 

Horning,  J.J.;  Some  Desirable  Properties  of  Data  Abstraction 
Facilities;  Proceedings  Conference  on  Data,  SIGPLAN  Notices 
Special  Issue  (1976)  pp. 60-62. 

This  paper  starts  with  the  analogy  between  the  advantages  data 
abstractions  offer  for  data  structures,  and  the  advantages 
procedures  offer  to  computational  structures.  Proceeding  from  the 
analogy,  the  advantages  offered  by  procedures  e  enumerated;  these 
are  then  related  to  data  abstractions  and  are  considered  to  be  the 
properties  of  data  abstraction.  Data  abstractions  are  not  treated 
as  generalizations  of  procedures  and  data  structures. 
Implementation  difficulties  are  discussed. 


HOROWITZ75 

Horowitz,  E. ;  Fortran  -  Can  It  Be  Structured  and  Should  It  Be?;  in 
Horowitz,  E.  (ed.).  Practical  Strategies  for  Developing  Large 
S eftware  Systems;  Addison-Wesley  (1975)  pp.  155-170. 
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Aware  of  the  rancor  he  will  receive  from  academics,  the  author 
recommends  the  use  of  a  structured  super-set  of  Fortran  for  some 
solid  practical  reasons.  As  well  as  some  of  the  standard  reasons 
for  structuring  (readable,  modifiable,  provable  programs) ,  reasons 
for  structuring  Fortran  include  the  easy  adoption  of  such  a 
language  by  the  current  generation  of  programmers.  Structured 
Fortran  can  be  compiled  with  little  extra  effort  and  cost  by 
running  the  structured  program  through  a  preprocessor. 


Having  justified  the  use  of  structured  Fortran,  the  author  surveys 
the  features  of  six  structured  Fortran  preprocessors.  He 
discusses  the  most  desirable  features  of  each  and  then  concludes 
with  a  summary  of  the  advantages  and  disadvantages  of  structured 
Fortr  an. 


HCWDEN76 

Howden,  W.E.;  Experiments  with  a  Symbolic  Evaluation  System;  AFIPS 
Conference  Proceedings  45  (1976)  pp. 899-908. 

The  introduction  to  this  paper  provides  a  brief  description  of  the 
notion  of  symbolic  program  execution.  The  symbolic  evaluation 
system  DISSECT  for  Fortran  programs  is  described.  Experiments 
with  DISSECT  on  programs  for  statistical  interpolation  and 
correlation  are  analyzed.  The  analysis  confirms  (but  does  not 
prove)  that  the  program  output  agrees  with  the  specifications. 


Unlike  other  symbolic  evaluation  systems  (e.g.,  EFFIGY),  DISSECT 
requires  the  user  to  divide  input  specif icationa  into  component 
case  specifications.  He  must  also  identify  the  parts  of  the 
program  intended  to  take  care  of  each  case. 

Since  the  author  has  made  no  assumptions  about  the  reader's 
previous  knwlee  of  symbolic  evaluation,  this  paper  is  a  good 
introduction  to  the  subject. 


ICHBIAH73 

Ichbiah,  J.D.,  Fissen,  J.P.,  and  Heliard,  J. C. ;  The  Two-Level 
Approach  to  Data  Independent  Programming  in  the  LIS  System 
Implementation  Language;  Proceedings  of  the  IFIP  TC-2  Conference 
on  Machine-Oriented  High-Level  Languages  (1973) . 


This  paper  describes  a  two-level  approach  to  defining  data 
structures  which  permits  separation  of  the  semantic  properties  of 
data  from  their  effective  implementation.  "implementation  parts" 
are  provided  for  specification  of  low-level  features  of  a 
structure  when  machine  dependencies  so  reguire.  The  syntactic  and 
semantic  implications  of  this  feature  are  discussed.  The  authors 
conclude  that  LIS  users  enjoy  the  advantages  of  a  high-level 
language  with  typechecking,  and  that  transferability  of  LIS 
programs  is  facilitated  by  the  isolation  of  machine-dependencies 
in  implementation  parts. 
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INMON76 

Inraon,  B. ;  An  Example  of  Structured  Design;  Datamation  22,3  (Mardh 
1976)  pp. 82,85-86. 

A  cost  accounting  system  was  developed  in  four  months  by  a  "chief 
programmer  team"  using  concepts  of  structured  programming  and 
structured  design.  A  high  programmer  productivity  rate  of 
approximately  11  lines  per  hour  was  achieved.  Rather  than 
efficiency,  the  main  design  goals  were:  speed,  accuracy,  program 
maintainability,  and  system  flexibility.  This  paper  provides  a 
good  description  of  the  few  disadvantages  and  many  advantages  of 
actually  applying  the  techniques  of  structured  programming  in  the 
development  of  a  real  life  situation. 


JARDINE7  5 

Jardine,  D.A.;  'Software  Engineering'  Aspects  of  Fourth-Generation 
Systems;  Software  Engineering  Education  Proceedings,  IBM 
Scientific  Symposium,  Montebello,  Quebec  (May  1975)  pp. 24-38. 

The  author  discusses  the  traditional  allocation  of  function  to 
software  rather  than  hardware;  he  indicates  evidence  of 
increasing  software  development  costs,  through  scrutiny  of  OS/360 
and  the  B6700  MCP  operating  systems.  The  increasing  importance  of 
data  management  software  in  IBM  and  Burroughs  is  described.  The 
expected  fourth  generation  machines  will  be  oriented  to  remote 
access  large  shared  data  base  systems.  Data  base  management 
systems  will  increase  in  complexity,  as  well  as  an  accompanying 
increase  in  control  program  complexity.  More  functions  will  be 
microcoded.  If  traditional  methods  are  followed,  a  first  release 
of  such  fourth  generation  machines  would  imply  costs  of  $109  for 
software  alone.  Such  costs  coupled  with  the  attendant  technical 
and  organizational  complexity,  and  maintenance  costs  would  render 
such  a  system  unfeasable.  New  approaches  must  therefore  be 
developed  before  attempting  to  implement  these  systems.  The 
author  suggests  new  approaches  in  eduction,  a  more  well-defined 
"software  engineering"  discipline,  and  investigation  of  large 
software  system  problems  in  educational  institutions.  Further,  he 
offers  implementation  ideas,  e.g.,  high-level  system 
inple mentation  languages,  use  of  networks  of  stand-alone 
minicomputers,  and  special  purpose  data  subsystems. 


JCNES76 

Jones,  M.N.;  HIPO  for  Developing  Specifications;  Datamation  22,3 
(March  1976)  pp.  1 1  2, 1 1 4, 1 21 , 1 25. 

HIPO  is  an  acronym  for  Hierarchy  plus  Input,  Process,  and  Output. 
It  was  originally  developed  as  a  formal  top-down  programming 
approach  by  IBM.  The  author  uses  the  technique  for  obtaining 
complete  and  accurate  user  specifications  that  can  be  easily 
translated  into  structured  programs  and  program  documentation. 
The  technique  involves  the  development  of  a  hierarchy  of 
specifications  in  which  every  "box"  has  a  single  input,  process, 
and  output.  A  description  is  provided  of  the  successful  use  of 
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H IPO  for  a  real  life  payroll  system  that  was  developed  on  schedule 
and  under  budget. 


KERNIGH AN74a 

Kernighan,  B.W.  and  Plauger,  P.J.;  The  Elements  of  Programming 
S  tyle ;  McGraw-Hill  (1974)  pp. 1-147. 


programs  and 
showing  the 
program,  the 
one  should 


This  book  should  probably  be  made  required  reading  for  all 
beginning  programmers  and  a  good  many  experienced  ones.  The 
authors  have  taken  a  large  number  of  published 

systematically  shown  the  errors  they  contain.  After 
reader  the  error  or  in  many  cases  the  errors  in  a 
error  types  are  generalized  into  a  rule  regarding  how 
avoid  making  these  errors.  Errors  have  been  classified  into 

common  pitfalls  which  programmers  invariably  fall  into.  The  saple 
programs  are  written  in  either  FORTRAN  or  PL/1  though  the  errors 
themselves  are  common  to  many  programming  languages.  It  should  be 
noted  that  this  is  not  a  book  about  structured  programming  per  se , 
but  more  a  book  about  how  to  avoid  making  the  small  logic  errors 
to  which  we  are  all  prone. 


KERNIGH AN74b 

Kernighan,  B.W.  and  Plauger,  P. J. ;  Programming  Style: 
Counterexamples;  Computing  Surveys  6,4  (December  1974 


CR28 ,103 
Examples  and 
pp. 303-319. 


This  paper  is  a 
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survey  of  some  aspects  of  programming  style 
amples,  that  programs  written  with  good  styl 
and  understand,  and  often  smaller  and 
hose  written  badly.  The  authors  discuss  va 
from  programming  text  books,  and  illustrat 
rove  these  example  programs.  Throughout, 
mostly  about  expression  and  structure, 
essions  on  robustness,  efficiency 
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KIMBL  ETON7  2  CR23,879 
Kimbleton,  S.R.;  Performance  Evaluation  -  A  Structured  Approach; 
Proceedings  of  the  SJCC  40  (1972)  pp. 411-416. 

This  paper  is  concerned  with  evaluating  the  performance  of  a 
computer  system,  including  its  operating  system.  Although  directed 
towards  evaluation  for  purposes  of  selection  and  comparison,  the 
ideas  presented  are  relevant  with  regard  to  the  improvement  or 
evaluation  of  a  particular  programming  or  operating  system  for  a 
particular  machine.  In  particular,  the  point  is  made  that  usually 
a  few  key  variables  drive  the  entire  system. 

KING76 

King,  J.C.;  Symbolic  Execution  and  Program  Testing;  CACM  19,7 
(July  1976)  pp. 385-394. 


-4  8- 


Current  Articles 


The  author  describes  an  approach  to  testing  between  the  extremes 
of  sample  data  testing  and  formal  proof  of  correctness.  A  program 
is  "symbolically"  executed  for  a  set  of  classes  of  inputs.  The 
symbolic  output  is  then  checked  manually  for  correctness.  While 
the  author’s  description  of  symbolic  execution  is  based  on  rather 
strong  assumptions  (e.g.  only  integer  operations) ,  it  does  provide 
a  basis  for  discussion  of  such  a  technique  for  program  testing. 
Unlike  Floyd's  proofs  for  correctness,  the  inputs  for  symbolic 
execution  include  "path  conditions"  for  IF  statement  execution.  A 
description  of  the  interactive  symbolic  execution  system  EFFIGY 
written  in  PL/I  style  syntax  is  included  as  well  as  examples  of 
its  use. 


KNUTH73a 

Knuth,  D.E.;  A  Review  of  Structured  Programming:  Stanford 

University,  Department  of  Computer  Science,  Technical  Report  STAN- 
CS-73-37 1  (June  1973) . 

This  report  contains  a  detailed  review  of  the  book  Structured 
Programming  in  the  form  of  letters  to  each  of  the  three  authors 
(Dahl,  Dijkstra,  and  Hoare) .  Each  letter  is  opened  with  very 
flattering  compliments  to  the  author,  and  then  discusses,  in  a 
point  by  point  fashion,  many  (sometimes  minute)  details  of  that 
author's  chapter  in  the  book. 

Knuth 's  points  are  too  numerous  to  list.  They  are  often 
controversial,  inspiring  one  to  reread  portions  of  the  book  to 
refresh  his  memory  and  "take  sides."  Especially  interesting  is 
Knuth 's  application  of  Simula  classes  (from  Dahl's  chapter)  to  a 
problem  which  Dijkstra  solves  in  his  chapter. 


KNUTH73b 

Knuth,  D.E.;  The  Art  of  Computer  Programming 
Searc  Addison-Wesley  (1973)  pp.722. 


CR25, 533 
V  3/Sorting  and 


This 

and 

eleme 

"  opt  i 

techn 

searc 

inclu 

techn 

keys , 

analy 

relia 

an  im 


book  is  an  excellent  survey  of  sorting  techniques  (chapter  5) 
searching  techniques  (chapter  6).  The  author  covers 
ntary  techniques  of  internal  sorting  as  well  as  various 
mum"  sorting  techniques.  He  covers  many  tape  sorting 

iques,  with  a  brief  word  on  disk  sorting.  In  the  chapter  on 
hing,  he  covers  several  tree  representation  techniques, 
ding  Fredkin's  TRIE,  as  well  as  several  hash  coding 
iques,  some  of  which  prove  useful  for  retrieval  on  secondary 
a  topic  of  current  interest  when  associated  with  "data  base" 
sis.  Knuth* s  presentation  seems  weakened  a  little  by  his 
nee  on  MIX,  an  assembler  language  of  his  own  derivation  for 
aginary  machine. 


KNUTH74 

Knuth,  D.E.;  Structured  Programming  with  go  to  Statements; 
Computing  Surveys  6,4  (December  1974)  pp. 261-301. 
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An  important  and  controversial 
opinion  of  this  paper  is,  one  will 
wishes  to  discuss  structured 
bibliography  as  well. 


paper.  No  matter  what  one's 
have  had  to  have  read  it  if  one 
programming.  It  has  a  nice 


KOSINS  KI7  3 

Kosinski,  P.R.;  A  Data  Flow  Programming  Language;  IBM  EC  4264 
(March  1973)  pp. 1-134. 

A  two  dimensional  Data-flow  language  devised  by  the  author  is 
described.  This  language  has  the  property  of  having  no  variables, 
and  no  control  flow  primitives.  Although  the  language  is  not  very 
useful,  the  ideas  involved  are  interesting. 


KULSRUD74 

Kulsrud,  K.E.;  Some  Statistics  on  Reasons  for  Compiler  Use; 
Software  -  Practice  and  Experience  4,3  ( July-September  1974) 
pp. 241-249. 

This  paper  describes  a  distribution  of  Compiler-time  usage.  Based 
on  a  statistical  survey,  the  author  reports  user's  time  used  in 
program  writing,  program  correction,  program  checking  etc.  The 
languages  used  in  the  survey  are  FORTRAN  and  IMP.  No  concrete 
conclusions  are  given  but  it  may  lead  to  further  investigations  in 
the  area  of  "better  programming  languages." 


LA  NZ AR0NE72 
Lanzarone,  G.A.; 
Computer  Journal 


Proof  of  Program  Correctness: 
6,1  (1972)  pp. 38-42. 


Lanzarone  gives  a  concise  review  of  the 
program  correctness.  He  briefly  describes  and 
verification  schemes.  The  work  of  Floyd, 
discussed. 


a  Review;  Honeywell 


state  of  the  art  of 
comments  on  several 
Maurer  and  Allen  is 


LASSETTRE72 

Lassettre,  E.R.,  and  Scherr,  A.L.;  Modelling 
the  OS/360  Time-Sharing  Option  (TSO) ;  in 
Statistical  Computer  Performance  Evaluation, 
pp.  57-72. 


CR2  4,594 
the  Performance  of 
Freiberger,  W.  (ed.)  , 
Academic  Press  (1972) 


When  properly  handled,  modelling  can  be  an  invaluable  tool  in  the 
design  of  a  performance-bound  software  system.  This  paper 
describes  an  extremely  successful  application  of  modelling  to  the 
design,  debugging  and  modification  of  a  fairly  complex  operating 
system . 

Measurements  taken  during  the  implementation  of  TSO  were 
continually  compared  to  the  predictions  of  the  model,  a  reasonably 
simple  analytical  one  calibrated  and  driven  by  observations  of 
other  systems.  The  "accuracy"  of  the  model  was  such  that 
perfomance  discrepancies  were  usually  traced  to  bugs  in  TSO 
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itself.  The  model  thus  served  at  least  two  purposes:  early 
prediction  of  ultimate  performance,  and  identification  of 
performance  problems  during  implementation. 


LEAVEN W0RTH72  CR24,148 
Leavenworth,  B.M.;  Programming  With  (out)  the  GOTO;  Proceedings  of 
the  ACM  1972  Annual  Conference  (1972)  pp. 782-786. 


The  author  presents  a  brief  history  of  the  GOTO  controversy.  The 
GOTO  does  not  appear  in  formal  systems  such  as  the  Post  system  or 
Kleene  general  recursive  functions,  but  has  been  added  to 
programming  languages.  The  existence  of  the  GOTO  as  a  primitive 
operation  on  machines  has  influenced  the  design  of  high  level 
languages.  The  author  summarizes  both  sides  of  the  argument.  In 
its  favor,  the  GOTO  is  needed  for  abnormal  exits  from  blocks  or 
procedures,  efficient,  useful  for  synthesis  purposes.  However, 
programs  without  GOTOs  are  more  easily  understood,  debugged,  and 
modified.  It  is  easier  to  prove  assertions  about  programs  which 
contain  no  GOTOs.  Finally,  the  GOTO  is  freguently  misused  to 
synthesize  more  sophisticated  control  structures. 


LEDGARD75 

Ledgard,  H.F.,  and  Marcotty,  M. ;  A  Genealogy  of  Control 
Structures;  CACM  18,11  (November  1975)  pp. 629-639. 

This  paper  presents  a  framework  for  reviewing  theoretical  results 
on  the  limitations  of  various  control  structures,  and  discusses 
the  practical  implication  of  these  results.  The  framework 
consists  of:  (1)  definition  of  a  classification  of  control 
structures  that  includes  most  control  structures  explicitly  found 
in  conventional  languages,  (2)  a  set  of  conversion  criteria  that 
classifies  the  type  of  conversion  from  one  control  structure  to 
another,  and  (3)  the  notions  of  reducability  and  equivalence  of 
classes  of  control  structures  that,  coupled  with  the  conversion 
criteria,  allow  discussion  of  the  relative  power  of  classes  of 
control  structures. 

Within  this  framework  two  theoretical  results  on  the  relative 
power  of  control  structures  are  discussed:  (a)  the  Boehm-Jac opini 
result  of  theoretical  completeness  of  if-then-else  and  while-do, 
and  (b)  the  Kosaraju  result  of  a  hierarchical  arrangement  of 
classes  of  control  structures  by  relative  power. 

Finally,  the  implications  of  the  theoretical  results  to  the 
practising  programmer  are  considered.  From  this  pragmatic 
viewpoint,  the  idea  of  converting  one  class  of  control  structures 
tc  another  is  questionable;  in  actual  programming,  emphasis  is 
placed  on  the  naturalness  of  a  control  structure  to  express  a 
solution.  An  example  is  presented  where,  in  one  case,  a  program  is 
reqritten  by  conversion  to  a  second  class  of  control  structures; 
in  the  second  case,  the  program  is  coded  from  the  start  in  the 
second  class  of  control  structures.  The  code  of  the  second  case  is 
clearly  better. 
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The  conclusion  is  that  theoretical  results  based  on  program 
ccnvesion  may  not  have  any  practical  significance.  Thus,  the  need 
for  higher  level  constructs  (above  if-then-else,  do-while,  and 
variants)  remains  unproven. 


LINDEN76 

Linden,  T.A.;  The  Use  of  Abstract  Data  Types  to  Simplify  Program 
Modifications;  Proceedings  of  Conference  on  Data,  SIGPLAN  Notices 
Special  Issue  (1976)  pp. 12-23. 

The  paper  introduces  the  concept  of  abstract  data  types  and 
motivation  for  their  use  as  module  units.  This  introduction 
provides  a  very  good  description  of  the  meaning  and  development  of 
data  abstraction.  The  abstract  data  type  is  described  as  the 
generalization  of  the  data  type  and  the  procedure;  as  such,  it 
should  be  preferred  over  the  procedure  as  the  unit  of  modularity. 

The  existing  implementations  and  uses  of  abstract  data  types  are 
presented,  along  with  their  limitations.  The  importance  of 
abstract  data  types  in  protecting  a  data  structure  from  arbitrary 
reference  is  discussed;  its  importance  is  of  particular  concern 
when  the  data  is  complex,  inconsistent,  or  high- security .  Various 
advantages  of  abstract  data  types  are  given,  such  as  the 
appropriateness  as  a  unit  of  modularity  for  systems  using  the 
Dijkstra  hierarchical  structure  (especially  in  contrast  to  the 
awkwardness  of  simple  procedures);  the  effectiveness  of  abstract 
data  types  in  documenting  programming  project  design  decisions; 
the  similarity  of  the  abstract  data  type  to  program  specification 
techniques  being  advocated.  The  author  suggests  designing  and 
structuring  a  program  using  abstract  data  types,  even  if  the 
target  language  does  not  support  them. 

The  example  program  presented  is  small,  but  nonetheless,  it 
demonstrates  the  elegance  and  power  of  abstract  data  types.  The 
program  structure  is  immediately  apparent.  After  four 
mcdif icaticns  representing  staged  development  of  efficiency,  the 
program  remains  almost  identical,  all  changes  taking  place  in  the 
abstract  data  type  definition. 

This  paper  is  well  worth  reading.  The  effectiveness  of  the 
abstract  data  is  best  summarized  as  follows:  "..  if  the  abstract 
data  type  is  viewed  as  providing  an  abstract  machine  for  the 
execution  of  the  [sample]  program,  then  all  of  these  modifications 
can  be  seen  as  changes  made  to  the  abstract  machine  to  provide 
better  support  for  this  particular  algorithm". 


LISKOV72 

Liskov,  B.H.;  A  Design  Methodology  for  Reliable  Software 
Proceedings  of  the  FJCC  41  (1972)  pp. 191-199. 


CR2  5,795 
Systems ; 


This  paper  presents 
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then  describes  a  two-part  methodology  derived  from  her  own 
experience  with  a  large  software  project. 

The  first  part  involves  the  definition  of  a  ’‘good"  system 
modularization,  in  which  the  system  is  organized  into  a  hierarchy 
of  11  part itions"  each  corresponding  to  a  level  of  abstraction,  and 
having  minimal  connections  with  one  another.  The  total  system 
design  is  then  expressed  as  a  structured  program,  rendering  the 
design  amenable  to  existing  proof  technigues. 

The  second  part  looks  at  the  question  of  how  to  achieve  a  system 
design  with  good  modularity.  The  key  to  the  design  is  seen  by  the 
author  as  the  identification  of  "useful"  abstractions  which  help 
the  designer  to  think  about  the  system.  Some  techniques  for 
finding  such  abstractions  are  given.  A  definition  of  "end  of 
design"  is  given,  involving  having  a  system  design  with  the 
desired  structure,  and  a  preliminary  user's  guide. 

The  paper  ends  by  describing  experiments  in  the  use  of  the 
methodology  in  progress  at  the  time  of  presentation. 


LISKOV73 

Liskov,  B.;  Report  of  Session  on  Structured  Programming;  SIGPLAN 
Notices  8,9  (September  1973)  pp.5-10. 

An  overview  of  the  definition  of  structured  programming  is  given, 
including  levels  of  abstraction,  abstract  data,  etc.  The 
discussion  includes  sections  on  monitors,  protection,  and 
construction  of  structured  programs  as  well  as  linguistic  features 
which  should  be  provided  by  a  structured  programming  language. 


LISK0V74 

Liskov,  B.H.,  and  Zilles,  S.;  Programming  with  Abstract  Data 
Types;  Proceedings  of  the  Symposium  on  Very  High  Level  Languages, 
SIGPLAN  Notices  9,4  (April  1974)  pp. 50-59. 

This  paper  describes  an  approach  to  programming  based  on  data 
types  and  functional  abstraction.  The  approach  evolved  from  work 
on  designing  a  language  for  structured  programming,  and  language 
features  supporting  the  use  of  abstraction  for  structured 
programming  are  discussed.  These  features  include  modular 
compilation,  permitting  the  programmer  to  abstract  upon  other 
abstractions;  two  forms  of  modules:  procedures,  to  support 
functional  abstraction,  and  operation  clusters  (which  define  a 
data  type  and  all  allowable  operations  on  that  type),  to  support 
data  type  abstraction;  restricted  access  to  these  modules  through 
cluster  names  and  procedure  names  only;  extensive  type  checking; 
and  only  structured  control  constructs  (no  goto) . 

These  features  are  illustrated  using  programming  examples.  The 
syntax  seems  slightly  awkward,  but  the  authors  assert  that  the 
awkwardness  enhances  underst andability.  The  paper's  relationship 
to  previous  work  is  reviewed,  and  implementation  considerations 
are  discussed. 
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LISK0V75 

Liskov,  B.H.,  and  Zilles,  S.N.;  Specification  Techniques  for  Data 
Abstractions;  IEEE  Transactions  on  Software  Engineering  SE-1,1 
(March  1975)  pp.7-19. 

This  paper  discusses  the  importance  of  formal  specifications, 
presents  the  data  abstraction  as  the  specification  unit,  and 
analyzes  and  compares  various  specification  techniques  for 
describing  data  abstractions.  Numerous  works  in  this  area  are 
cited,  and  directions  for  future  research  in  specification 
techniques  for  data  abstractions  are  indicated. 

Formal  specifications  are  a  means  to  facilitate  formal  or  informal 
proofs  of  program  correctness.  They  are  interposed  between  a 
concept  and  the  programs  implementing  the  concept.  Thus,  proofs 
are  based  on  examining  this  specification  to  program  link. 
Furthermore,  the  advantages  of  formal  specifications  are  the 
possibility  of  machine  verification  of  programs,  the  improvement 
of  program  description,  use  as  a  design  aid,  formal  specifications 
as  a  communication  medium  among  a  program's  designers,  and  the 
ability  to  resolve  ambiguities  of  specification. 

This  paper  offers  a  good  look  at  research  done  in  the  area  of 
formal  specification  techniques  and  data  abstractions;  It  also 
offers  an  extensive  bibliography.  The  paper  presents  a  number  of 
interesting  problems  that  deserve  further  research. 


LOESER  76 

Loeser,  R.,  and  Gaposchkin,  E.M. ;  The  Second  Law  of  Debugging; 
Software  -  Practice  and  Experience  6,4  (October-December  1976) 
pp. 577-578. 

This  paper  after  acknowledging  that,  in  spite  of  error  reducing 
methodologies,  programs  still  contain  bugs,  states  the  second  law 
of  debugging:  'if  you  don't  see  the  bug  where  you're  looking, 
then  you're  not  looking  in  the  right  place'.  This  is  something 
all  programmers  should  remember.  This  is  an  article  well  worth 
the  few  minutes  required  to  read  it. 


LDCAS73 

Lucas,  H.C.,  and  Presser,  L. ;  A  Method  of  Software  Evaluation:  the 
Case  of  Language  Translators;  The  Computer  Journal  16,3  (August 
1  973)  pp. 226-231  . 

This  paper  presents  a  method  of  evaluating  software,  in 
particular,  language  translators.  A  set  of  14  characteristics  for 
quantitative  comparison  of  language  translators  is  given.  The 
design  of  synthetic  benchmark  programs  to  evaluate  some  of  these 
characteristics  is  described.  In  the  specific  evaluation  example 
given,  the  evaluation  concludes  that  WATFIV  is  superior  to  IBM 
FORTRAN  G  or  H,  in  an  installation  where  much  time  is  spent 
debugging  -  not  a  very  profound  result.  How  to  perform  an 
evaluation  along  similar  lines,  where  the  specifications  are  not 
as  well-defined,  or  where  the  software  is  not  both  finished. 
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debugged,  and  available  for  use,  or  where  a  decision  must  be  made 
between  two  available  programs  with  different  specifications,  is 
not  clear  from  this  paper. 


M ANNA73 

Manna,  Z.,  Ness,  S.,  Vuillemin,  J.;  Inductive  Methods  for  Proving 
Properties  of  Programs;  CACM  16,8  (August  1973)  pp. 491-502. 

This  paper  is  a  readable  introduction  to  program  proving.  It 
explains  a  quantity  of  basic  concepts  and  several  methods  of 
proving  programs.  There  are  no  unexplained  terms  that  an  average 
student  should  not  know  already.  Several  examples  are  worked 
through. 


MARCOTTY74  CR27,168 
Marcotty,  M.,  Schultz,  H.;  The  Systems  Programming  Language  MALUS; 
Software  -  Practice  and  Experience  4,1  ( January-March  1974)  pp.79- 
90. 

MALUS,  a  dialect  of  PL/I  and  an  outgrowth  of  XPL  is  described.  It 
is  a  compiler  which  can  compile  itself,  and  has  been  used  at  CDC 
to  implement  a  multi-console  time  sharing  system  (MCTS)  on  the 
STAR- 100  and  STAR-65  computers.  Their  success,  as  described  under 
"evaluation,"  may  well  spell  the  doom  of  assembly  languages  for 
the  implementation  of  operating  systems,  for  the  instruction  set 
for  the  STAR  computer  is  very  complicated  indeed,  yet  the  authors 
did  net  feel  restricted  by  their  use  of  a  high-level  language  to 
implement  a  timesharing  operating  system. 


MARGOLIN72 

Margolin,  E.H.,  Parmelee,  R.P.,  and  Schatzoff,  M. ;  Analysis  of 
Free  Storage  Algorithms;  in  Freiberger,  W.  (ed.),  Statistica 1 
Computer  Performance  Evaluation,  Academic  Press  (1972). 

A  description  of  an  excellent  melding  of  system  measurement, 
statistical  techniques,  modelling  and  experiment  design  which 
resulted  in  a  substantial  improvement  in  the  CP-67  operating 
system.  Highly  recommended  to  those  interested  in  banging  existing 
software  into  shape. 


MARTI N74 

Martin,  J.J.;  Generalized  Structured  Programming;  AFIPS  Conference 
Proceedings  43  (1974)  pp. 665-669. 

This  paper  is  of  interest  to  all  who  have  read  any  of  Dijkstra' s 
papers  on  structured  programming.  Martin  is  suggesting  that 
currently  accepted  structured  programming  constructs  be 
generalized.  It  is  the  author*s  claim  that  Dijkstra' s  constructs 
are  too  restrictive,  and  actually  lower  program  understandabilit y 
through  the  necessity  of  programming  steps  "that  are  motivated 
solely  by  structural  restrictions  imposed  by  rules  of  style."  The 
author  cites  particularly  that  Dijkstra' s  constructs  require  undue 
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program  complexity  to  compute  complex  conditions,  since  the  use  of 
condition  flags  is  often  required. 

To  correct  this  handicap  Martin  proposes  a  new  set  of  constructs 
which  form  a  superset  of  Dijkstra  's.  The  claim  is  made  that  the 
main  advantage  of  structured  programming,  program  decomposability, 
is  not  lost  with  this  expanded  construct  set.  To  make  these  new 
constructs  clearer,  actual  language  syntax  of  new  statement  types 
that  emulate  the  theoretical  constructs  is  presented. 


MATUSZEK76 

Matuszek,  D.;  The  Case  for  The  Assert  Statement;  SIGPLAN  Notices 
11,8  (August  1976)  pp. 36-37. 

This  paper  first  presents  a  brief  definition  of  an  Assert 
statement  as  it  might  be  defined  in  an  ALGOL  like  language.  The 
author  claims  that  such  a  construct  would  be  useful  for  both 
debugging  and  documentation  purposes  and  has  the  other  attractive 
benefit  of  being  something  that  programmers  would  use.  He  also 
suggests  several  possible  extensions  of  the  Assert  statement. 


MAYNARD72  CR23,645 

Maynard,  J. ;  Modular  Programming,;  Butterworths,  London  (1972) 

pp. 1-  100. 


The  observations  of  a  professional  programmer  on  the  methods  of 
modular  programming  and  its  benefits  in  cost,  management  control, 
flexibility,  and  program  maintenance.  The  traditional  " monoli thic " 
program  is  criticized  for  its  inherent  fragility  after  debugging, 
the  duplication  of  effort  involved,  and  the  mismatch  of  programmer 
talent  to  problem  that  usually  occurs.  A  step-by-step  design, 
decomposition,  and  implementation  of  a  commercial  problem,  is 
given  with  reference  to  FORTRAN,  COBOL,  PL/I,  /360  assembler,  and 
to  interface  methods.  The  form  of  a  module  library  for  a  software 
procedure  is  discussed. 


MCCLURE75 

McClure,  C.L.;  Top-Down,  Eottom-Up,  and  Structured  Programming; 
IEEE  Transactions  on  Software  Engineering  SE-1,4  (December  1975) 
pp. 397-403. 

An  analysis  of  top-down  and  bottom-up  programming  is  given 
together  with  a  good  example  of  each.  It  is  argued  that 
structured  programming  does  not  consist  of  top-down  or  bottom-up 
programming  by  themselves,  buth  rather  the  good  use  of  them, 
probably  at  the  same  time.  The  author  states  that  in  many 
applications  both  are  really  used  since  the  top-down  programmer 
may  back  up  when  he  learns  something  at  a  lower  development  level, 
and  use  the  new  information  at  a  more  abstract  level.  On  the 
other  hand,  a  bottom-up  programmer  bears  in  mind  the  top  level 
requirements  and  often  "peeks"  ahead. 
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MCCRACKEN72  CR24,910 
McCracken,  D.D.,  and  Weinberg,  G.M.;  How  to  Write  a  Readable 
FORTRAN  Program;  Datamation  18,10  (October  1972)  pp. 73-77. 

For  ease  of  documentation  and  for  readability,  programmers  should 
observe  the  described  rules  concerning  comments,  "goto"s,  do- 
loops,  complicated  expressions,  statement  numbers  and  variable 
names. 


MCKEEM AN72 

McKeeman,  W.M.;  Compiler  Structure;  Technical  Report  23,  Computer 
Systems  Research  Group,  University  of  Toronto  (January  1973). 


MCKEEMAN74 

McKeeman,  W.M.;  Programming  Language  Design,  in  ‘'Compiler 
Construction:  An  Advanced  Course,"  F.L.  Bauer,  Editor,  Springer- 
Verlag,  Berlin  (1974)  514-524. 

McKeeman  describes  the  levels  in  what  he  calls  the  problem  solving 
tower,  and  points  out  that  the  language  designer's  task  is  to 
facilitate  the  programming  process,  which  takes  place  at  all  of 
the  levels  of  abstraction  of  the  problem  solving  tower.  The  major 
issues  are  what  structures  are  useful  at  each  of  the  various 
levels  of  abstraction,  and  "the  new  viewpoint  is  that  it  is  not 
necessary  to  mix  all  the  levels  into  one  notation.  Or,  to  put  it 
differently,  it  was  a  mistake  to  assume  we  could  think  effectively 
in  a  (single)  programming  language." 


Several  design  principles  and  desirable  properties  are  stated: 
simplicity,  use  of  established  constructs,  involution, 
orthogonality,  adequacy,  tr anslatability ,  and  the  ability  to 
mirror  human  thought  patterns.  A  list  of  important  features  of  a 
language  not  necessary  (er  even  advisable)  to  have  all  at  one 
level,  include:  assertions,  hierarchical  decomposition,  modular 
decomposition,  data  structuring,  abstraction,  sequencing,  data 
manipulation,  and  redundancy.  The  Algol  languages,  mathematics, 
and  street  languages  are  models  used  for  the  purpose  of 
illustration  of  the  above  features. 

In  this  paper,  McKeeman  has  provided  an  insightful  description  of 
the  problem  solving  process,  and  as  such  it  is  well  worth  being 
read  by  software  engineers  as  well  as  programming  language 
designers. 


MCKEE  MAN7  5 

McKeeman,  W.M.;  On  Preventing  Programming  Languages  from 
Interfering  with  Programming;  IEEE  Transactions  on  Software 
Engineering  SE-1,1  (March  1975),  pp. 19-26. 

A  breakdown  of  the  traditional  8-queens  problem  using  a  top-down 
approach  based  on  proving  the  program  in  the  end.  The  proof  of 
the  program  is  developed  in  parallel  with  the  program  usina  top- 
down  approach  for  each.  The  author  advocates  the  necessity  of 
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this  type  of  program 


programming  languages  which  facilitate 
development . 


M ILL  ER  72 

Miller,  E.F.;  Bibliograpy  on  Techniques  of  Computer  Perfomance 
Analysis;  Computer  5,5  (September /October  1972)  pp. 39-47. 


Though  many  of  the 
oriented,  there  are 
structuring  programs 
efficiency. 


entries  in  this  bibliography  are  system- 
still  more  which  can  provide  ideas  for 
in  an  attempt  to  improve  their  operating 


MILLER74 

Miller,  L.A.;  Programming  by  Non-Programmers;  International 
Journal  of  Man-Machine  Studies  6,2  (March  1974)  pp. 237-260. 

This  article  is  a  study  on  the  result  of  one  attempt  to  extend  the 
understanding  of  the  behavioural  processes  and  problems  involved 
in  programming.  Twelve  non-programmers  solved  six  problems 
similar  in  nature  but  different  in  tests  (affirmation  vs. 
negation)  and  relations  (conjunction  vs.  disjunction). 

The  results  confirmed  earlier  results  that  negation  and 
disjunction  were  more  difficult  concepts  to  program  correctly. 
Certain  control  structures  were  identified  as  being  easier  to  use, 
and  it  was  noted  that  debugging  took  an  inordinate  amount  of  time 
with  respect  to  the  initial  programming.  The  conclusions  bear  out 
what  some  people  already  feel  to  be  intuitively  obvious.  In 
particular,  the  structure  of  the  program  is  found  to  be  important 
to  its  efficiency  and  correctness. 


MILLS  7  2 

Mills,  H.D.;  Mathematical  Foundations  For  Structured  Programming; 
IBM  Federal  Systems  Division  7BFSC  72-6012  (February  1972)  pp.  1  - 

6  2. 

The  author  attempts  to  provide  mathematical  assurance  that  a 
technical  standard  for  structured  programming  techniques  is  sound 
and  practical.  He  observes  a  psychological  side-effect  of  using 
structured  programming:  the  programmer,  having  greater  assurance 
that  his  program  will  be  correct,  is  motivated  to  a  new  level  of 
concentration,  which  in  turn  reduces  errors  even  more.  He 
describes  programs  in  the  form  of  control  graphs,  and  proves  a 
"structure  theorem":  Any  proper  program  is  equivalent  to  a  program 
whose  formula  contains  at  most  the  BLOCK,  IF-THEN-ELSE,  and  DO- 
UNTIL,  and  additional  functions  TRUE,  FALSE,  POP,  and  predicate 
function  TOP." 

The  advantages  of  program  structure  in  program  correctness  proofs 
are  shown,  and  the  production  of  these  programs  by  topdown 
expansion  is  discussed. 
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MILLS  7  3a 

Mills,  H. ;  The  Complexity  of  Programs;  in  Hetzel,  W.C.  (ed.); 
Program  Test  Methods ;  Prentice-Hall,  Englewood  Cliffs  (1973) 
pp.  22  5-23  8. 

Mills  begins  by  pointing  out  that,  "in  computer  programming,  we 
have  not  yet  discovered  that  complexity  has  weight."  He  goes  on  to 
discuss  the  role  of  structured  programming,  the  complexity  of 
understanding  programs  and  proving  programs  correct.  He  defines 
two  types  of  programs:  rational  and  natural,  which  refer  to  the 
knowledge  available  about  the  internal  mechanism  of  the  program.  A 
rational  program  is  one  whose  internal  mechanism  is  transparent  to 
some  people;  a  natural  program  is  one  whose  internal  mechanism  is 
known  to  no  one.  Programs  begin  in  the  rational  state  and 
eventually  pass  on  to  the  natural  state  where  they  soon  become 
obsolete.  His  objective  in  measuring  and  controlling  complexity 
is  to  keep  a  program  rational  for  as  long  as  possible,  and 
certainly  much  longer  than  at  present,  before  the  inevitable  rot 
sets  in. 


MILLS7  3b 

Mills,  H.D.;  On  the  Development  of  Large  Reliable  Programs;  IEEE 
Symposium  on  Computer  Software  Reliability,  New  York  (April  1973) 
pp. 155-159. 

In  this  paper  Mills  describes  operational  procedures  intended  for 
the  development  of  large  reliable  programs.  These  procedures  are 
based  on  top  down  structured  programming  to  provide  small 
structured  program  segments  which  facilitate  reading  of  program 
text  and  testing.  With  respect  to  overall  program  correctness,  the 
approach  taken  is  that  rather  than  have  to  claim  that  the  last 
error  has  been  found  (if  that  is  possible)  one  should  strive  to 
never  find  the  first  error.  Mills  feels  this  can  be  accomplished 
by  restructuring  programming  from  a  private  art  into  a  public 
practice  by  having  programs  read  by  others.  Finally,  the  paper 
introduces  the  concept  of  program  development  accounting  as  a 
means  to  record  the  process  of  program  development  and  inspection, 
and  to  provide  proof  of  the  successfulness  of  the  concept  of  never 
finding  a  first  error  in  the  program. 


MILLS75 

Mills,  H.D.;  How  to  Write  Correct  Programs  and  Know  It; 
Proceedings  International  Conference  on  Reliable  Software,  SIGPLAN 
Notices  10,6  (June  1975)  pp. 363-370. 

The  general  attitude  expressed  in  this  paper  is  that  the  reader  is 
being  sold  some  new  and  wonderful  product.  A  description  of 
structured  programming  is  presented  to  readers  who  are  assumed 
adherents  of  "the  cut-and-try  process  of  frustration  and  anxiety" 
when  programming.  Structured  programming  is  advocated  as  a  means 
of  writing  programs  that  are  not  only  correct,  but  are 
convincingly  correct  to  others.  There  is  no  proof  that  a  program 
is  error-free;  the  real  opportunity  of  knowing  that  a  program  is 
correct  is  if  the  first  error  is  never  found,  despite  numerous 
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runs,  tests,  etc.  The  objective  of  programming  is  writing  correct 
programs  from  the  start.  The  way  to  reach  this  objective  is 
though  structured  programming. 

The  remainder  of  the  paper  demonstrates  the  aspects  of  structured 
programming  by  illustrating  the  structure  of  three  search 
routines.  The  paper  contains  quite  a  comprehensive  bibliography 
on  ideas  and  research  in  structured  programming. 


MITCHELL76 

M ichell ,  J.,  and  Hegbreit,  B. ;  A  Next  Step  in  Data  Structuring  for 
Programming  Languages;  Proceedings  Conference  on  Data,  SIGPLAN 
Notices  Special  Issue  (1976)  pp. 69-70. 


This  paper  discusses  implementation  of  data  abstractions  in  terms 
of  research  done  in  generalizing  the  notion  of  parameterized 
types.  A  framework  proposal  is  presented  for  this  research. 
Implementation  could  be  carried  out  through  two  related  language 
constructs:  abstract ion .  which  is  the  uncommitted  statement  of 
the  properties  of  a  data  type,  and  scheme.  which  is  a  module 
taking  values  and  data  types  as  parameters. 


MCRRI S73a 

Morris,  F.L.;  Advice  on  Structuring  Compilers  and  Proving  Them 
Correct;  ACM  Symposium  on  Principles  of  Programming  Languages 
(October  1973)  pp. 144-152. 

The  author  directs  his  attention  to  proving  compiler  correctness. 
His  approach  is  algebraic,  and  entails  defining  the  source 
language,  target  language  and  their  respective  meanings  as 
heterogeneous  algebras,  then  defining  homomorphisms  (one  of  which 
represents  the  compiler)  between  these  algebras.  The  paper  deals 
mostly  with  an  example  of  the  development  and  proof  of  a  small 
compiler.  Although  this  method  proves  to  be  very  powerful,  it 
requires  considerable  background  knowledge  before  it  becomes 
understandable.  This  is  not  an  introductory  paper  by  any 
standards,  but  if  one  is  prepared  to  work  through  it  carefully,  it 
proves  to  be  extremely  worthwhile. 


M0RRIS73b 

Morris,  J.E.;  Programming  by  Semantic  Refinement;  SIGPLAN  Notices 
8,9  (September  1973)  pp. 120-122. 

Programmers  are  incapable  of  efficiently  producing  reliable 
programs  when  they  are  initially  confronted  with  the  detail  of  the 
final  program.  Semantic  refinement  is  offered  as  a  graduated 
approach  from  an  abstract  design  to  a  final  implementation.  This 
is  achieved  by  coding  and  debugging  the  system  in  a  series  of  more 
precise  languages,  the  last  of  which  is  a  systems  implementation 
1  an  guage . 
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MORR IS  73c 

Morris,  J.H.;  Protection  in  Programming  Languages;  CACM  16,1 
(January  1973)  pp.  15-21. 

Morris  discusses  a  series  of  methods  of  protection  from  hostile 
programs.  It  is  noted  that  a  hostile  program  can  be  either  from  a 
competing  business  or  agency,  or  it  can  just  as  easily  be  your  own 
program  which  contains  bugs.  Included  in  the  list  of  devices  are 
discussions  about  procedures  as  objects,  local  objects,  type 
protection,  memory  protection,  seals,  and  trademarks.  For  memory 
protection,  one  may  make  reference  to  the  object  local  to  a 
procedure  R.  In  order  to  provide  outside  access,  the  programmer 
can  provide  reference  to  procedures  within  R.  Seals  are  a  method 
of  ensuring  that  a  programmer  has  taken  the  correct  steps  prior  to 
accessing  a  function,  and  aids  in  localization  of  accesses. 


MORRI S73d 

Morris,  J.H.;  Types  are  not  Sets;  ACM  Symposium  on  Principles  of 
Programming  Languages  (October  1973)  pp. 120-124. 

The  author  argues  that  objects  of  a  type  should  be  should  be 
managed  (i.e.,  created  and  operated  on)  by  the  owner  of  that 
object.  He  proposes  a  module  block,  which  can  selectively  provide 
local  symbols  to  its  users,  including  the  names  of  types.  A 
module  has  sole  write  access  to  values  of  its  local  types,  but  may 
give  out  read  access  to  such  values  if  it  chooses.  Proof  rules 
are  discussed  for  verifying  correct  use  of  modules.  Finally,  the 
author  relates  Simula  classes  and  polymorphic  functions  to  his 
modules. 


MCSED AIE73 

Mosedale,  T.W.;  PEDANT:  A  Computerized  Support  to  Program 
Modularity  Under  Limited  Memory  Conditions;  Software  -  Practice 
and  Experience  3,2  (April-June  1973)  pp.  121-143. 

The  author  notes  that  the  "building  block  approach"  is  already 
used  in  hardware,  and  suggests  its  extension  to  software.  He 
points  out  that  modularity  does  not  always  eliminate  the 
driver/buffer  program,  but  requires  a  skillfully  created 
interface.  PEDANT  is  designed  to  work  with  large  modules,  to 
simplify  applications  where  memory  size  is  small.  Data  areas  are 
considered  to  be  undefined  until  referenced,  and  thus  outside  the 
module  blocks.  PEDANT,  acting  as  an  interpreter,  handles  all 
requests  for  data,  and  for  communication  with  other  modules. 
PEDANT  is  basically  a  link  and  load  software  system.  Modules  can 
ignore  the  source  of  data  (i.e.,  in-core,  disk,  tape)  and  can 
treat  data  as  a  resource. 


M  YERS73 

Myers,  G.J.;  Characteristics  of  Composite  Design;  Datamation  19,9 
(September  1973)  pp. 100-102. 


-61- 


Current  Articles 


An  essentially  unsatisfying  discussion  of  design  criteria  for 
highly  modular  programs.  Suggests  that  the  goal  is  a  program 
composed  of  "strong1’  (closely- coupled  internally)  modules,  each 
with  a  well-defined  function  and  predictable  results,  linked  by  as 
few  arguments  as  possible.  No  real  life  example  of  such  design,  or 
its  supposed  advantages  (quickly  written,  easily  debugged,  easily 
changed)  is  provided. 


Program  structure  follows  social  structure  (Turski70) .  The  two 
key  statements  in  the  paper  are:  "Because  of  the  high 

independence  within  the  program,  interactions  and  dependencies 
among  programmers  are  reduced."  "Programmer  assignments  can  be 
easily  shifted  to  smooth  out  the  peaks  and  valleys  on  resource 
requirements, " 


N  ASS  17  3 

Nassi,  I.,  and  Schneider ma n,  B;  Flowchart  Techniques  for 
Structured  Programming;  SIGPLAN  Notices  8,  8  (August  1973)  pp.12- 
2  7. 

With  the  acceptance  of  structured,  top-down,  gotoless  programming, 
a  computational  model  is  needed  which  prevents  unrestricted 
transfers  of  control  and  reflects  the  control  structure  of  the 
languages  suitable  for  structured  programming.  Some  advantages  of 
the  flowcharting  language  presented  are  that  the  scope  of 
iterations  and  IF-THEN-ELSE  clauses  are  well  defined  and  visible, 
that  the  scope  of  variables  is  obvious,  and  that  arbitrary 
transfers  of  control  are  impossible. 


NAUE72  CP2  5,213 

Naur,  P. ;  An  Experiment  in  Program  Development;  BIT  12,3  (1972) 

pp. 347-365. 

This  paper  contains  a  detailed,  step  by  step  account  of  the 
considerations  leading  to  a  program  for  solving  the  "8-queens 
Problem."  In  the  author*s  opinion  at  least  some  program 
development  does  not,  and  can  hardly  be  made  to,  proceed  as  a  top- 
down  process  as  advocated  by  Dijkstra  and  Wirth.  Bather,  a 
problem  solving  type  of  process  is  taking  place  in  solving  such 
problems.  In  this  process  high  level  program  descriptions  appear, 
but  only  after  important  details  have  been  explored  at  a  lower 
level . 


NEELY73  CR27,210 
Neely,  P.M.;  On  Program  Control  Structure;  Proceedings  of  the  ACM 
Conference  (1973)  pp. 119-125. 

This  paper  is  primarily  concerned  with  the  improvement  of  the 
syntactic  format  of  DO-WHILE  loops.  The  improvements  take  two 
forms,  first  a  standard  set  of  indentation  rules  to  make  reading 
the  code  easier,  and  second  the  semantics  of  the  logical  control 
of  iteration  are  separated  from  the  semantics  of  the  body  of  the 
loop. 


-62- 


Current  Articles 


Unfortunately  the  paper  has  imbedded  in  it  examples  in  FORTRAN. 
However  several  new  statement  types  are  suggested  including 
variants  of  the  DO-WHILE  loop  and  also  a  POSIT-Q UIT- ADMIT 
statement  which  would  be  of  particular  value  in  error  handling 
within  loop  bodies.  The  author  claims  that  by  using  his  suggested 
indentation  rules  and  syntax  one  can  insert  comments  into  any 
programming  language  code  so  that  the  code  is  described  in  terms 
of  a  particular  fixed  set  of  statement  types.  The  statement  types 
need  not  be  implemented  in  the  given  language,  but  the  comments 
would  emulate  the  syntax.  Thus,  the  theory  is,  a  programmer  would 
be  able  to  read  code  in  any  language  even  though  he  might  not  know 
the  particular  language  syntax. 


NEELY76 

Neely,  P.M.;  A 
Experience  6,1 


New  Programming  Discipline;  Software  -  Practice  and 
(January  -  March  1976)  pp.7-27. 


The  author  has  observed  a  lack  of  communication  between  advocates 
of  structured  programming  and  scientific  programmers.  This  paper 
is  an  attempt  to  demonstrate  the  use  and  importance  of  structured 
programming  for  scientific  applications  using  FORTRAN, 
brief  historical  review  of  structured  programming, 
suggests  some  practical  modifications  to  "pure” 
programming.  His  main  concern  is  that  the  type  of 
programming  used  by  scientific  programmers  produce  comprehensible 
programs  that  can  be  easily  debugged  and  tested  for  correctness. 
Examples  of  short  structured  FORTRAN  programs  are  provided. 
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NC0NAN75 

Noonan,  R.E.;  Structured  Programming  and  Formal  Specification; 
IEEE  Transactions  on  Software  Engineering  SE-1,4  (December  1975) 
pp. 421-425. 

The  belief  is  expressed  that  not  all  programs  should  use  the  same 
scrt  of  specification  methods;  they  may  well  change  with  the  type 
of  program.  As  an  example,  a  text  processing  example  is  given  for 
which  the  author  gives  specif icAtions  in  the  form  of  an  attribute 
grammar.  He  then  develops  the  program  for  his  example  from  these 
specifications.  It  is  hinted  that  using  different  forms  of 
specification  methods  aids  verification,  but  does  not  actually 
indicate  how  to  verify  programs  derived  from  his  attribute  grammar 
system. 


0GDIN73 

Ogdin,  J.L.;  Improving  Software  Reliability;  Datamation  19,1 
(January  1973)  pp. 49-52. 

This  paper  tries  to  develop  ways  for  improving  software 
reliability,  using  modular  programming.  The  author  first  makes  a 
general  comparison  of  a  program  to  a  mathematical  function, 
showing  the  many  similarities  that  exist,  and  then  narrows  this 
comparison  to  tasks  and  modules. 
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In  an  effort  to  provide  for  more  reliable  software,  the  author 
discusses  several  relevant  areas,  such  as  where  the  decisions 
should  be  made  in  hierarchies  of  tasks  and  the  problem  of  changing 
specifications  for  written  modules.  When  the  modules  are 
redefined,  they  should  be  renamed.  Finally,  program  bugs  are 
classified  and  then  reasons  and  solutions  are  given  for  them. 


ORGAN ICK72  CR24,104 

Or ga nick,  E. I . ;  The  Multics  System:  An  Examination  of  its 

Structure ;  MIT  Press,  Cambridge,  Massachusetts  (1972)  pp.  1-392. 


OSTER WEIL76 

Osterweil,  L.J.,  and  Fosdick,  L. D. ;  Some  Experience  with  DAVE  -  A 
Fortran  Program  Analyzer;  AFIPS  Conference  Proceedings  45  (1976) 
pp. 909-915. 

DAVE  is  an  automatic  program  testing  aid  for  Fortran  programs. 
While  it  operates  on  a  static,  non-executable  program,  it  contains 
some  features  that  allow  it  to  simulate  the  effect  of  executing 
the  pregram  through  every  possible  path.  It  flags  any  statement 
in  which  an  uninitialized  variable  is  used  in  computation.  It 
flags  any  variable  that  is  assigned  a  value  but  never  used.  After 
using  DAVE,  the  programmer  examines  "suspicious"  situations  and  if 
necessary  executes  them  with  test  data  to  confirm  or  reject  the 
suspicion  raised  by  DAVE. 

The  paper  includes  an  example  of  the  use  of  DAVE;  it  demonstrates 
that  the  type  of  errors  detected  are  often  symptoms  of  subtle, 
more  serious  errors.  DAVE  was  able  to  detect  errors  in  recent 
algorithms  in  ACM  Transactions  on  Mathematical  Software  and  in  a 
program  in  a  computer  science  Master's  Thesis. 


PARNAS72a 

Parnas,  D.L.;  A  Course  on  Software  Engineering  Techniques;  SIGCSE 
Bulletin  4,1  (March  1972)  pp.  154-^159. 


PARNA  S72b  CR23,949 
Parnas,  D.L.;  A  Technique  for  Software  Module  Specifications  with 
Examples;  CACM  15,5  (May  1972)  pp. 330-336. 

An  approach  to  writing  software  specifications  for  parts  of 
systems  is  presented.  This  is  an  example  of  Dijkstra's  principle 
of  non-interference.  The  technique  attempts  to  provide 
specifications  with  sufficient  information  to  allow  interaction  of 
the  parts  only  as  a  whole.  Parnas  suggests  a  structure  where 
specifications  could  be  tested  for  completeness  and  correctness 
before  detailed  coding.  Although  the  idea  is  at  a  young  stage  his 
analysis  to  this  point  is  useful  and  worth  noting. 
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PAFNAS72C 

Parnas,  D.L.;  On  the  Criteria 
Modules;  CACM  15,12  (December 


CR2  5, 197 

Used  in  Decomposing  Systems  into 
1972)  pp. 1 053-1 058. 


Modularization  involves  decomposition  of  the  problem  into  modules 
corresponding  to  each  major  step  in  the  processing.  Parnas  shows 
by  example  that  modifying  the  data  structure  specifications  (i.e., 
storage  media,  packing  of  information,  input  format)  would  require 
an  extensive  rewriting  of  most  modules.  He  suggests  that  for 
systems  greater  than  5,000-10,000  instructions ,  the  criterion  of 
'information  hiding'  be  used  to  guide  decomposition.  Every  module 
is  characterized  by  a  design  decision  it  hides  from  all  other 
modules.  Although  efficient  implementation  may  involve  a 
reshuffling  of  the  module  code  to  produce  the  final  system, 
maintaining  both  levels  of  code  would  combat  this  objection. 


P  ARN  AS72d  CR25,506 
Parnas,  D.I.;  Some  Conclusions  from  an  Experiment  in  Software 
Engineering  Techniques;  Proceedings  of  the  EJCC  41  (1972)  pp.325- 
329. 

Describes  a  student  group  project  to  test  the  methodology  outlined 
by  the  same  author  elsewhere.  Once  the  problem  has  been  carefully 
partitioned  into  five  modules,  each  module  was  assigned  to  several 
different  students,  sometimes  with  different  internal 
specifications  for  each  student.  Care  is  taken  in  the 
decomposition  to  see  that  details  such  as  data  structures  and 
access  methods  are  "known"  to  as  few  modules  as  possible,  usually 
only  one.  The  result  of  the  experiment,  192  working  combinations 
out  of  a  possible  1024,  is  regarded  as  a  success  considering:  the 
students  were  generally  poor  programmers,  some  modules  were  not 
finished,  the  language  used  was  WATFIV,  etc.  The  final  integration 
and  testing  of  modules  was  done  by  someone  with  "absolute  no 
knowledge  of  the  structure  of  any  module." 


PARNAS72e  CR25,351 
Parnas,  D.L.;  Information  Distribution  Aspects  of  Design 
Methodology;  Proceedings  of  IFIP  Congress  71  (1972)  pp. 339-344. 


The  thesis  of  this  paper  is  that  a  designer  may  retain  ti 
control  on  the  structure  of  his  system  if  he  controls 
distribution  of  information.  Parnas  observes  that  "a 
programmer  makes  use  of  the  useable  information  given  him." 
ccnseguence  is  that  a  good  programmer,  given  all  the  inform 
about  the  system  design  will  always  find  some  efficiencies  in 
twiddling."  The  unfortunate  side  effect  is  that  modules  b 
highly  interconnected,  making  for  nasty  problems  later  in 
design.  Restriction  of  information  distribution  reduces 
interdependency.  Information  about  design  decisions  can  no 
used,  by  the  designer,  to  verify  that  the  code  produc 
consistent  with  design  objectives.  Several  good  examples 
given  which  support  the  theme  of  the  paper. 
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PARNAS72f 

Parnas  D.L.;  Response  to  Detected  Errors  in  Well-Structured 
Programs;  Carnegie-Mellon  University,  Department  of  Computer 
Science  (July  1972)  pp.1-18. 

The  author's  main  assumption  is  that  even  well-structured  programs 
will  have  run-time  errors  and  hence  reliable  systems  have  to  be 
designed  with  error  handling  and  self-diagnosis  as  a  fundamental 
consideration.  The  foremost  problem  with  error  handling  in  a 
structured  program  is  that  the  level  of  abstraction  where  the 
error  is  detected  is  usually  lower  than  the  level  where 
information  fcr  proper  response  to  that  error  is  available. 

A  methodology  for  module  design  based  on  the  concept  of  the 
software  analog  of  the  hardware  "trap”  is  presented  to  deal  with 
this  problem.  The  "software  trap"  technique  allows  error 

conditions  to  be  "reflected"  up  through  levels  of  abtraction  while 
maintaining  a  structured  discipline. 

A  detailed  example  of  such  a  design  is  given  along  with 
suggestions  of  what  type  of  applications  would  benefit  from  the 
discussed  methods. 


P  ARN  AS 75 

Parnas,  D.L.;  The  Influence  of  Software  Structure  on  Reliability; 
Proceedings  International  Conference  on  Reliable  Software,  Los 
Angeles,  SIGPLAN  Notices  10,6  (June  1975)  pp. 358-362. 


The  author  argues  that  correctness 
synonymous.  Correctness  refers  to 
reliability  refers  to  meeting  demands 
the  production  of  correct  software 
concerning  which  much  has  been  written, 
is  on  the  production  of 
increased  by  careful 
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(i.e. ,  the  structure)  at  an  early  stage  in  the  des 
appendix  to  the  article  provides  an  example  of  the 
guestions  that  should  be  considered  in  the  design  of  a 
communications  support  system. 
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P  ARN  AS76a 

Parnas,  D.L.,  Shore,  J.E.,  and  Weiss,  D. ;  Abstract  Data  Types 
Defined  as  Classes  of  Variables;  Proceedings  of  Conference  on 
Data,  SIGPLAN  Notices  Special  Issue  (1976)  pp. 149-154. 

This  paper  concerns  itself  with  formulating  a  definition  of  data 
type  by  defining  the  attributes  that  such  an  animal  should  posess. 
The  authors  feel  for  a  number  of  reasons,  that  previous  attempts 
in  this  direction  are  either  inadequate  or  too  restrictive.  The 
definition  given  is  complete  and  each  aspect  is  motivated  thus 
providing  the  reader  with  a  good  feeling  for  both  what  an  Abstract 
data  type  is  and  why.  This  is  a  highly  recommended  paper  for 
anyone  wishing  to  know  about  abstract  data  types. 
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P  ARN  AS76  b 

Parnas,  D.L.;  On  the  Design  and  Development  of  Program  Families; 
IEEE  Transactions  on  Software  Engineering  SE-2,1  (March  1976) 
pp . 1- 9 . 

Programs  in  a  given  family  are  related  by  having  been  derived  from 
the  same  intermediate  description  which  occured  during  stepwise 
refinement.  The  roles  of  stepwise  refinement  and  module 
specification  (abstract  data  types)  in  structured  programming  are 
examined,  although  not  in  detail.  The  author  advocates  that  both 
techniques  should  be  used  together,  complementing  rather  than 
competing  with  each  other.  The  author  proposes  the  use  of  proof 
justifications  as  an  augment  to  verification  assertions  in 
programs.  Proof  justifications  inform  the  verifier  how  to  proceed 
in  verification  of  each  of  the  possible  cases  which  can  arise  for 
a  given  assertion.  It  is  shown  that  proof  justifications  allow 
the  elimination  of  quantifiers  from  assertional  formulas,  greatly 
simplifying  the  verification  task.  To  prevent  justifications  from 
becoming  overly  verbose,  a  system  of  default  justifications  is 
used . 


PEARS0N73 

Pearson,  K.M.;  Cataloguing  Computer  Software;  Datamation  19,10 
(October  1973)  pp. 87-91. 

This  article  discusses  the  present  methods  of  cataloguing  systems 
software,  and  argues  that  it  is  inadequate.  Instead,  the  author 
espouses  his  own  system,  involving  complete  description  and 
interfacing  facilities.  In  particular,  he  argues  that  the  name  of 
the  programmer  should  be  included,  since  a  knowledge  of  the 
programming  style  of  an  individual  can  give  a  good  idea  of  the 
probable  structure  of  the  program. 


PETERS0N73  CR26,120 

Peterson,  W.W.,  Kasami,  T.,  Tokura,  N.;  On  the  Capabilities  of 
While,  Repeat,  and  Exit  Statements;  CACM  16,8  (August  1973) 
pp.  50  3-512. 

Using  a  flowchart  formalism  similar  to  [Ashcroft  71],  this  paper 
also  describes  a  GOTO  removing  transformation  for  programs  using 
arbitrary  GOTOs.  This  transformation  results  in  a  GOTO-free 
program  which,  in  general,  is  longer  than  the  original,  but  which 
has  the  same  execution  time  as  the  original.  (Both  length  and 
execution  time  are  increased  by  the  transformation  of  Ashcroft  and 
Manna).  These  transformed  programs,  however,  make  use  of  the 
repeat  and  multi-level  exit  primitives  (in  addition  to  if-then- 
else)  .  The  absence  of  this  multi-level  exit  from  most  current 
programming  languages  (SUE  and  other  languages  with  this  primitive 
are  not  mentioned)  ,  and  its  positive  or  negative  contribution  to 
the  under standability  of  programs,  are  not  discussed. 


POOIE73  CR2  6,539 

Poole,  P.C.;  Debugging  and  Testing;  in  Bauer,  F.L.  (ed.).  Advanced 
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Course  on  Software  Engineering;  S pringer-Verlag,  New  York  (1973) 
pp.  278-318. 

The  author  points  out  that  since  every  program  written  will  have 
errors,  it  is  most  important  that  programmers  write  their  programs 
allowing  for  ease  of  subseguent  testing  and  debugging  (unlike 
present  practice,  which  tends  to  assume  the  program  will  work 
without  error).  He  suggests  planning  for  the  testing  and 
debugging  phases.  In  particular,  "debugging  code"  should  be  put 
in  right  at  the  start  —  rather  than  having  it  inserted  when  bugs 
arise.  The  most  useful  form  of  debugging  code  would  be  one  which 
would  remain  in  the  program  in  its  final  form,  but  would  not  be 
executed  unless  desired  (when,  for  example,  a  new  bug  appears) . 
The  use  of  debugging  code,  a  modular  program  structure,  and 
parameterization  of  important  variables  would  make  testing  and 
debugging  much  easier.  A  discussion  is  given  of  classical 
debugging  techniques  —  most  of  which  have  the  problem  of 
generating  too  much  output  in  an  awkward  form  for  analysis.  On¬ 
line  debugging  seems  popular,  but  has  problems  (principally,  how 
to  manipulate  compiled  code) .  New  debugging  and  testing  aids 
should  also  take  into  account  the  fact  that  corrections  to  present 
programs  are  often  not  fully  tested  or  documented  because  the 
debugging  and  testing  methods  are  awkward  and  time  consuming. 


PROKOP73  CR2  5,  52  9 
Prokop,  J.S.;  On  Proving  the  Correctness  of  Computer  Programs;  in 
Hetzel,  W.C.  (ed. )  ;  Program  Test  Methods;  Prentice-Hall,  Englewood 
Cliffs  (1973)  pp. 29-37. 

Various  ways  of  proving  program  correctness,  both  formal  and 
informal,  are  examined.  When  all  the  complex  factors  which  act  on 
a  program  during  the  four  stages  of  analysis,  coding,  compilation 
and  object  are  considered  it  is  concluded  (not  too  surprisingly) 
that  current  proof  techniques  are  impractical  on  anything  but 
fairly  trivial  problems.  It  is  concluded  that  "we  are  not  very 
much  advanced  in  the  art  or  science  of  proving  computer  programs 
to  be  correct."  A  plea  is  made  for  the  "transference  of  proof 
techniques  into  a  production  environment  for  computer  programs 
which  are  somewhere  in  the  middle  of  the  continuum  from  trivial  to 
impossible." 


R  A IN 7 3  CR2  5,20  4 

Rain,  M. ;  Two  Unusual  Methods  for  Debugging  System  Software; 
Software  -  Practice  and  Experience  3,1  (January-March  1973) 
pp. 6 1- 63. 

In  the  first  part  of  the  paper,  the  author  suggests  an  automated 
approach  to  bug-finding.  A  program  should  be  written,  capable  of 
accepting  a  correct  source-language  program,  and  randomizing  the 
program  according  to  an  adjustable  randomization  factor.  In  the 
second  part,  "bug  contests"  are  suggested,  wherin  users  might  be 
encouraged  to  throughly  test  new  software,  and  at  the  same  time 
expand  their  knowledge  of  the  capabilities  of  the  software,  by 
offering  cash  rewards  for  each  previously  undetected  bug  or  quirk. 
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R AMAM00RTHY75 

Ramamoorthy,  C.V.,  Ho,  S.-B.,F. ;  Testing  Large  Software  with 
Automated  Software  Evaluation  Systems;  IEEE  Transactions  on 
Software  Engineering  SE-1,1  (March  1975)  pp. 46-58. 

This  paper  points  out  that  the  major  expense  in  computer  systems 
at  present  and  in  the  future  is  software.  Since  proving  large- 
scale  software  systems  correct  by  formal  proof  is  currently 
infeasible,  the  authors  present  automated  software  tools  as 
valuable  instruments  for  improving  software  reliability  and 
reducing  the  high  cost  of  software  systems. 

The  paper  begins  by  discussing  the  two  basic  requirements  for  all 
software  systems  (correctness  and  performance)  and  the  problems 
involved  in  achieving  these  requirements.  The  classifications  of 
automated  tools  are  given  and  the  main  features  and  functions  of 
these  tools  are  described.  An  example  of  the  application  of  a 
linear  programming  technique  to  the  selection  of  an  optimal  set  of 
automated  tools  for  implementation  in  a  software  evaluation  system 
is  given.  The  performances  of  three  actual  automated  software 
evaluation  systems  FACES,  ACES,  and  PACE  -  are  discussed.  The 
authors  conclude  that  partial  validation  with  the  aid  of  software 
evaluation  systems  appears  to  be  the  most  cost  effective  approach 
to  improving  the  reliability  of  large  software  systems. 

This  article  can  serve  as  an  introduction  to  the  area  of  automated 
software  evaluation.  Terminology  and  concepts  associated  with 
this  area  are  explained,  and  it  would  be  of  interest  to  those  with 
little  background  in  this  field.  For  those  more  knowledgeable, 
the  chief  interest  would  be  the  references  to  more  in-depth 
information. 


RANDELL72 
Randell,  B.; 
Reliability; 


CR2 5,107 

Operating  Systems:  The  Problems  of  Performance  and 
Proceedings  of  IFIP  Congress  71  (1972)  pp. 281-290. 


R  ANDELL7 5 

Randell,  E.;  System  Structure  for  Software  Fault  Tolerance;  IEEE 
Transactions  on  Software  Engineering  SE-1,2  (June  1975)  pp.220- 
232. 

The  author  presents  a  methodology  for  error  recovery  using 
recovery  blocks.  Recovery  blocks  allow  the  specification  of 
alternates  for  a  section  of  code,  to  be  executed  if  a  user 
supplied  acceptance  test  is  not  true  upon  exit  from  the  section  of 
code.  In  particular,  the  paper  addresses  the  problems  involved  in 
the  state  restoration  which  occurs  before  an  alternate  is  tried. 
State  restoration  in  both  sequential  and  multi-processing 
environments  are  examined. 


RIDDLE72 

Riddle,  W.E.;  An  Annotated  Bibliography  on  Software  Architecture; 
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Stanford  Linear  Accelerator  Center,  Computation  Group,  no.  138 
(September  1972)  pp. 1-103. 


RCCHKIND75 

Rochkind,  M.J.;  The  Source  Code  Control  System;  IEEE  Transactions 
on  Software  Engineering  SE-1,4  (December  1975)  pp. 364-370. 

The  Source  Code  Control  System  (SCCS)  developed  at  Bell 
Laboratories  is  described.  This  system  retains  versions  of  a 
source  code  file  by  retaining  the  original  file  as  well  as  a 
number  of  deltas,  units  of  change  which  raise  the  software  to  the 
next  level  or  version.  Any  accessing  of  the  code  is  done  by 
specifying  the  original  file  as  well  as  which  deltas  are  to  be 
applied  to  it.  The  system  also  matches  source  and  object  modules 
by  time  stamping  the  source  code  and  hence,  through  compilation, 
the  object  code.  An  interesting  article  about  a  relatively  new 
aspect  of  software  engineering. 


R0SS76 

Ross,  D. ;  Toward  Foundations  of  the  Understanding  of  Type; 
Proceedings  Conference  on  Data,  SIGPLAN  Notices  Special  Issue 
(1976)  pp. 63-65. 

This  is  a  somewhat  philosophical  and  formalistic  approach  to 
defining  abstract  data  types. 


ROYCE75 

Royce,  W.W.;  Software  Requirements  Analysis;  Sizing  and  Costing; 
in  Horowitz,  E.  (ed.).  Practical  Strategies  for  Developing  Large 
Software  Systems ;  Addison- We sle y  (1975)  pp. 57-71. 

This  paper  asserts  the  importance  of  the  development  of  systems 
requirements  in  a  top-down  fashion.  All  aspects  of  system  design 
except  design  of  critical  modules  and  untried  processes  should  be 
left  until  the  general  system  reguirememnts  and  more  refined 
specific  reguirememnts  are  complete.  The  paper  includes 
guidelines  for  costing  and  emphasizes  the  importance  of  validating 
requirements.  The  author  describes  five  approaches  of  requirement 
validation.  In  order  of  increasing  fidelity  and  cost,  they  are: 
estimation,  off-the-shelf  simulation,  new  simulation,  prototype 
development,  and  do-it-twice.  Since  simulation  is  the  most 
popular  approach,  it  is  described  in  more  detail.  In  conclusion, 
the  author  suggests  four  techniques  that  would  aid  in  the  process 
of  developing  requirements  analysis. 


SATTERTHWAITE72  CR24,408 

Satterth waite,  E.;  Debugging  Tcols  for  High-Level  Languages; 
Software  -  Practice  and  Experience  2,3  ( July- Se ptember  1972) 

pp.  197-217. 

This  article  stresses  the  need  for  reviving  the  dialogue  between 
man  and  machine,  which  was  lost  in  the  transition  to  higher- level 
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languages.  As  an  example  of  a  modest  but  significant  step  toward 
such  a  revival,  the  author  describes  a  programming  system  using 
Algol  W  "which  supports  a  range  of  debugging  tools  and  techniques, 
all  based  entirely  upon  the  high  level  language  used  by  the 
programmer."  Four  design  criteria  were  specified: 

1)  All  information  to  the  user  should  be  expressed  in  terms  of 
his  program  and  Algol  W. 

2)  The  compiler  should  produce  machine  code,  which  should  not  be 
significantly  degraded  by  debugging  requirements,  and  which  should 
execute  at  full  hardware  speed  when  not  in  debugging  mode. 

3)  Resource  requirements,  especially  I/O,  should  be  moderate 
enough  for  use  by  students  with  limited  budgets. 

4)  Debugging  tools  should  be  easy  to  invoke,  and  default 
information  should  encourage  programmers  to  critically  re-examine 
their  programs,  as  well  as  help  programmers  in  diagnosing  program 
failure. 

Discussed  were  system  organization  and  aspects  of  the  /360 
i nple mentation  of  the  debugging  system.  Performance  of  this 
implementation  was  evaluated  for  Algol  W  programs  chosen  from  a 
variety  of  diverse  applications. 

The  system  is  not  the  programmer's  answer  to  debugging,  but  it  has 
gone  a  significant  way  in  providing  an  example  of  useful,  easy-to- 
invoke  feedback  to  those  programming  in  high-level  languages. 


SCHNEIDER MAN73 

Schne ider man ,  B.,  and  Scheuerman,  P.;  Structured  Data  Structures; 
State  University  of  New  York  at  Stony  Brook,  Department  of 
Computer  Science,  Technical  Report  16  (June  1973)  pp.1-34. 

The  report  proposes  a  Data  Structure  Description  and  Manipulation 
language  (DSDMI)  which  provides  for  the  creation  of  a  restricted 
class  of  data  structures,  but  ensures  the  correctness  of  the 
program.  This  is  accomplished  by  having  the  user  explicitly 
declare  the  form  of  the  structure  (e.g.,  list,  tree,  ring,  queue, 
stack  and  degue) ,  restrict  the  permissible  operations  on  the 
structure,  and  specify  execution  time  checks  to  ensure  the  form  of 
the  structure  is  not  altered  (e.g.,  by  the  insertion  of  some 
pointer) .  The  authors  claim  that  they  wish  to  eliminate 
unrestricted  branches  or  edges  (i.e.,  pointers)  from  data 
structures  just  as  the  goto  has  been  eliminated  to  avoid  poorly 
structured  programs.  They  also  claim  that  using  their  system  top- 
dcwn  programming  can  be  achieved  in  terms  of  data  structures  by 
having  the  nodes  of  a  given  level  structure  serve  as  headers  for 
the  structures  at  the  next  level. 


SCH WARTZ7  5 

Schwartz,  J.I.;  Construction  of  Software:  Problems  and 
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Practicalities;  in  Horowitz,  E.(ed.),  Pr act ical  Strategies  for 
D evel oping  Large  Software  Systems  ;  Addison -Wesley  (1975)  pp.  15-53. 


In  the  past  twenty-five  years,  the  size  and  complexity  of  sof 
has  increased  dramatically.  This  paper  concentrates  on  the 
of  the  data  processing  manager  and  programmer  in  building  th 
large-scale  systems.  The  author  analyses  the  problems  in 
areas  of  requirement  specification,  system  design,  program 
and  checkout.  For  each  area  he  describes  plans  and  techn 
that  should  help  avoid  or  alleviate  the  stated  problems, 
include  suggestions  for  budgeting,  personnel  selection,  choic 
programming  tools,  and  program  testing. 


While  there  are  no  new  ideas  in  this  paper,  the  autho 
successfully  summarized  many  of  the  techniques  that  will  pr 
the  production  of  reliable  large  scale  software. 


SCOTT 7  5 

Scott,  R.F.,  and  Simmons,  D.B.;  Predicting  Programming 
Productivity  -  A  Communications  Model;  IEEE  Transaction 
Software  Engineering  SE-1 ,4  (December  1975)  pp. 411-414. 
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SHAW72 

Shaw,  A.W.  and  Weiderman, 
Education  and  Research; 
pp. 1505-1509. 


CR2  5,285 

N.H.;  A  Multiprogramming  System  for 
Proceedings  of  IFIP  Congress  71  (1972) 


SHAW76 

Shaw,  M. ;  Research  Directions  in  Abstract  Data  Structures; 
Proceedings  Conference  on  Data,  SIGPLAN  Notices  Special  Issue 
(  1  976)  pp. 66-68. 


This  paper  discusses  problems  of 
incorporate  data  abstraction 
languages.  The  problems  are 
developing  the  ALPHARD  system. 


implementation  when 
mechansims  into 
discussed  in  the 


attempting  to 
pr  ogra  mming 
framework  of 


SHNEIDERMAN76 

Shneiderman,  E.;  A  Review  of  Design  Techniques  for  Programs  and 
Data;  Software  -  Practice  and  Experience  6,4  (October-Dec embe r 
1976)  pp. 555-567. 
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The  author  begins  this  paper  with  several  general  observations  on 
the  process  of  designing  programs.  The  design  me th cdol ogie s 
proposed  in  recent  years  by  Mills,  Wirth,  Dijkstra,  etc.,  should 
not  be  interpreted  as  rigid  doctrinaire,  he  claims,  but  rather  as 
a  set  of  strategies  to  choose  from  in  the  construction  of 
programs.  Certain  techniques  will  best  lend  themselves  to  a 
certain  class  of  problems  and  it  is  the  programmer  as  aritst's  job 
to  select  and  refine  the  best  technique  for  the  job.  The  paper 
continues  and  describes  in  broad  terms  the  classes  of  program  and 
data  structures  available  to  the  programmer  as  destinct  intities 
and  gives  the  methods  available  for  combining  the  two.  This 
article  is  an  excellent  introduction  to  the  software  engineering 
field  giving  a  survey  of  the  area  and  its  place  in  the  world  of 
programming. 


SHOOMAN75 

Shooman,  M.L.,  and  Bolsky,  M.I.;  Types,  Distribution,  and  Test  and 
Correction  Times  for  Programming  Errors;  Proceedings  International 
Conference  on  Reliable  Software,  SIGPLAN  Notices  10,6  (June  1975) 
pp. 347-357. 

This  paper  is  a  description  of  an  in-depth  software  experiment  on 

(a)  describing  types  of  errors:  their  nature  and  frequency, 

(b)  error  density,  and  (c)  debugging.  A  classification  of  errors 
was  designed  and  forms  were  filled  cut  by  programmers  working  on  a 
4K  ccntrcl  program.  Some  of  the  interesting  results  were:  number 
of  errors  was  1-1  1/2%  of  total  number  of  instructions;  bugs  that 
were  detected  by  hand  cost  1/25  of  those  detected  by  the  machine 
(incorrect  output),  and  55%  of  all  errors  were  detected  without 
the  use  of  a  computer. 


S IME7  3 

Sime,  M.E.,  Green,  T.R.G.,  and 
Evaluation  of  Two  Conditional 
Languages;  International  Journal 
(January  1973)  pp. 105-115. 


Guest ,  D. J. ; 

Constructs  Used 
of  Man-Machine 


CR2  5,30  9 
Psycholo  gical 
in  Computer 
Studies  5,  1 


Although  papers  comparing  structured  and  unstructured  languages 
exist,  very  little  hard  data  has  been  presented.  Most  studies 
talk  about  users  with  some  experience.  By  adopting  a  very 
simplified  language,  and  through  the  use  of  interactive  devices, 
the  authors  have  obtained  data  comparing  IF... GO  TO  to  a  nested  IF 
structure  using  non-experienced  users.  The  results  verify  the 
current  critisism  of  the  GOTO,  but  more  important  an  new  method  of 
studying  features  of  languages  is  presented. 


SIMMONS72 

Simmons,  D.B. ;  The  Art  of  Writing  Large  Programs;  Computer  5,2 
(March/April  1972)  pp. 43-49. 

This  article  is  oriented  towards  alleviating  problems  one 
encounters  when  writing  large  programs  and  improving  programmer 
productivity.  First,  many  factors  such  as  poor  communications  and 
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programmer  turnover  are  discussed  as  problem  areas  in  writing 
large  programs.  Then  techniques  for  improving  programmer 
productivity  are  discussed,  with  emphasis  on  improving 
communications  between  programmers  and  managers,  users,  and  the 
general  environment.  The  areas  dealt  with  are  programmer  task 
assignment  and  supervision,  programmer  environment,  programming 
techniques,  and  program  documentation.  Although  a  brief  treatment 
of  all  these  topics  is  given,  the  author  seems  to  touch  on  most 
major  areas  of  concern  and  offers  practical  advice  as  to  how  to 
write  large  programs. 


SITES74 

Sites,  R.L.;  Proving  that  computer  Programs  Terminate  Cleanly; 
Technical  Report  CS  418,  Stanford  University  (May  1974)  pp. 1-139. 

A  report  (based  on  a  thesis)  giving  practical  methods  to  determine 
if  a  loop  halts.  The  halting  problem  is  not  solved,  but  instances 
of  loop  simplification,  standardization  and  assertion  generation 
are  shown.  In  many  of  these  cases,  it  can  be  determined  if  a  loop 
is  exited.  Failure  to  exit  a  loop  because  cf  infinite  looping  or 
semantic  error  (e.g.,  overflow)  are  both  examined. 


SMITH  7  2a 
Smith  ,  D. ;  An 
Proceedings  of 


Organization  for  Successful  Project 
the  SJCC  40  (May  1972)  pp.  129-1  40. 


CR2  3,741 
Management ; 


Describes  some  of  the  major  problems  in  software  development 
including  those  associated  with  unsatisfactory  products,  schedule 
delays  and  excessive  costs.  Gives  a  good  top-down  project 
management  design  which  presents  most  of  the  major  ideas  in 
general  project  management,  but  is  overly  general  depending  too 
much  on  intuitive  ideas. 


S  MITH7 2b 

Smith,  J.M.;  Proof  and  Validation 
Computer  Journal  15,2  (May  1972)  pp, 


of  Program 
130-131 . 


CR24,582 
Correctness;  The 


The  author  points  out  that  ever  since  1962  when  McCarthy  raised 
the  concept  that  programs  should  be  proved  correct  rather  than 
merely  verified,  considerable  effort  has  been  devoted  to  the  study 
of  techniques  for  producing  such  proofs.  So  far  little  progress 
has  been  made  although  this  effort  has  lead  to  advances  in 
programming  languages,  theory  of  algorithms,  and  system  theory. 


The  author  proposes  that  it  may  not  be 
correctness  of  practical  programs  rigorously 
definition  of  program  correctness  as  stated 
basis  of  this  definition  is  the  concept  of  a 
•desired  result*.  In  general  it  is  not  alw 
this  desired  result  and  the  author  proposes 
program  validation  by  which  program  errors 
confidence  level  of  a  program  increased. 


possible  to  prove  the 
enough  to  satisfy  the 
by  Manna  in  1969.  The 
program  yielding  the 
ays  possible  to  define 
other  approaches  to 
can  be  reduced  and  the 
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SN0WDCN72 

Snowdon,  R.A.;  PEARL:  An  Interactive  System  for  the  Preparation 
and  Validation  of  Structured  Programs;  SIGPLAN  Notices  7,3  (March 
1972)  pp. 9-26 . 

The  author  describes  a  partially  implemented  interactive  system 
whose  purpose  is  to  assist  the  programmer  in  writing  structured 
programs.  Provisions  exist  in  PEARL  for  some  assistance  towards 
program  correctness.  The  system  restricts  its  attention  to  small, 
seguential  programs  designed  by  a  single  programmer. 


Initially,  an  ideal  "machine”  is  described,  both  by  the 
specification  of  its  data  types  and  operations,  and  by  a  program 
written  for  that  machine.  The  introduction  of  further  machines 
(and  programs  for  them)  serves  to  refine  the  meaning  of  previously 
introduced  programs  and  constructs.  Conditions  may  be  given  to 
operations  in  order  to  aid  in  ensuring  program  correctness  for  a 
particular  machine. 


The  system 
incompletely 
with  PEARL 
which  has  not 


has  various  facilities  for  program 
specified  programs  can  be  run,  as  well 
reguesting  assistance  upon  encounterin 
yet  been  fully  explained. 


editing,  and 
as  compiled , 
g  an  operation 


S  N0WD0N7  3 

Snowdon,  R.A.;  PEARL  -  A  System  for  the  Preparation  and  Validation 
of  Structured  Programs;  in  Hetzel,  W.C.(ed.),  Program  Test 
Methods;  Prentice-Hall  (1973)  pp. 57-72. 

The  PEARL  interactive  system  provides  a  programming  environment 
that  assists  an  individual  programmer  to  construct  short, 
seguential,  structured  programs  that  are  likely  to  be  correct. 


The  programmer  describes  an  ideal  "machine"  and  provides  a  program 
for  it.  He  continues  to  describe  further  machines  to  refine  the 
meanings  of  the  higher  level  ones.  Finally,  he  reaches  the  level 
of  machines  whose  programs  are  written  completely  in  terms  of  the 
"systems  programming  language".  As  well  as  the  program  for  each 
machine,  the  programmer  provides  correctness  criteria  such  as  pre¬ 
condition  and  post-condition  assertions.  Then  the  programmer  may 
execute  a  whole  or  partial  program  interactively  to  test  it 
against  the  correctness  criteria.  In  the  case  of  incomplete 
specifications,  the  user  is  cued  for  information. 


ST  AND IS  H7  5 

Standish,  T.A.;  Extensibility  in  Programming  Language  Design; 
SIGPLAN  Notices  10,7  (July  1975)  pp. 18-21. 

A  summary  of  the  aspirations  of  the  extensible  language  movement 
and  its  progress  to  date  is  presented.  This  paper  discusses  a 
variety  of  extension  techniques  that  have  been  developed,  and  what 
has  been  learned  about  extensibility  from  attempted 
implementations.  He  suggests  a  basic  difficulty  with  extensible 


75- 


Current  Articles 


to  their  full 


languages  is  the  effort  required  to  utilize  them 
capacity.  A  well-written  and  informative  article. 


STEELE75 

Steele,  T.E.;  Software  Engineering  - 
Engineering  Education  Proceedings, 
Montebello,  Quebec  (May  1975)  pp.9-15. 


Method 
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Software 
Symposium , 


The  main 

is  called 

software  engineering".  Although  the  issues  of  software 
engineering  are  aids  for  productivity,  documentation  and 
debugging,  software  engineering  is  itself  not  a  solution  to 
programming  problems;  it  is  a  miscsinception  to  use  the  term  since 
it  implies  a  disciplined  technology.  "Software  engineering"  is 
examined  with  regard  to  the  development,  over  centuries,  cf  modern 
engineering.  The  conclusion  from  this  analogy  is  that  it  is  still 
too  early  to  consider  establishing  a  technology;  we  are  only 
midway  through  stages  of  codification  of  problems  and 
experimentation.  Current  issues  of  "software  engineering"  would 
imply  that,  in  fact,  a  better  name  is:  "software  craftsmanship". 


STEVENS74 

Stevens,  W.P.,  Myers,  G.T.,  Constantine,  L. L. ; 
I  EM  Systems  Journal  13,2  (1974)  pp. 115-139. 


Structured  Design; 


The  authors  provide  the  suggestion  that  the  notion  of  structured 
programming  be  carried  further,  into  the  design  of  large  systems. 
The  importance  of  module  independence  is  discussed  in  some  depth, 
considerable  time  is  spent  in  the  paper  reviewing  the  degrees  of 
module  "cohesivness"  or  independence. 


The  authors 
help  reduce 
would  be 
independent 
also  would 
their  fixes 
system. 


suggest  that  a  library  of  modules  could  be  built  up  to 
system  generation  costs.  The  generation  of  a  system 
helped  by  using  pre- written  data  and  environment 
modules  that  require  no  debugging.  System  debugging 
be  a  less  costly  task  since  after  errors  are  traced 
would  not  have  side-effects  in  other  parts  of  the 


This  paper  strikes  at  the  core  of  software  engineering 
iterates  the  basic  principles  of  good  system  design. 


and  re- 


STONE72 
Stone  ,  M .  ; 
pp.  5  2-59. 


In  Search  of  An  Identity;  Datamation  18,3  (March  1972) 


The  author  attacks  the 
programmers  in  society.  A 
as  well  as  academia  is 
question  of  programmer  certification  is 
philosophical  and  a  practical  viewpoint. 


problem  of  the  professional  status  of 
broad  range  of  opinions  from  industry 
presented  in  an  unbiased  manner.  The 

examined  both  from  a 
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STUCKI75 

Stucki,  L.G.;  Automated  Tools  and  Techniques  Assisting  in  Software 
Development;  in  Horowitz,  E.  (ed.)  ,  Practical  Strategies  for 
Developing  Large  Software  Systems :  Addison- Wesley  (1975)  pp.171- 

189. 

The  author  describes  The  Program  Evaluator  and  Tester  (TPET) 
system  for  producing  self-metric  programs.  The  main  components 
are  a  preprocessor  that  generates  self-metric  programs  from 
existing  ones  and  a  postprocessor  that  generates  reports  of  the 
measurements.  In  the  Fortran  implementation  described,  the  output 
of  the  self-metric  programs  includes  such  information  as 
percentage  of  statements  executed,  results  of  conditional  tests, 
subroutines  called,  and  variable  ranges.  Since  unused  code  is 
indicated,  the  system  provides  useful  testing  information.  The 
author  concludes  the  paper  with  a  description  of  a  system  being 
designed  to  incorporate  the  current  techniques  with  other 
automated  aids  to  provide  a  general  Automated  Program  Support 
System  (APSS)  . 


TANENBAUM76 

Tanenbaum,  A.S.;  In  Defense  of  Program  Testing  or  Correctness 
Proofs  Considered  Harmful;  SIGPLAN  Notices  11,5  (May  1976)  pp.64- 
68. 


The  author  says  that  there  is  an  increasing  tendency  to  believe 
that  correctness  proofs  could  replace  testing.  He  believes  that 
proofs,  however,  are  at  best  supplements  but  not  substitutes  to 
comprehensive  testing. 

The  author  finds  fault  with  reliance  on  proofs  in  three  issues. 
First  is  the  human  effort  of  proving  correctness.  We  hardly  trust 
our  ability  to  program  correctly;  how  then  can  we  implicitly  trust 
our  ability  to  demonstrate  correctness,  a  task  more  difficult  them 
programming. 

The  next  issue  is  the  dependance  of  proofs  on  the  formal 
specifications.  No  proof  can  verify  the  compliance  of  the  formal 
specifications  to  a  concept;  it  can  only  demonstrate  the  program's 
action  in  light  of  the  specifications.  Furthermore,  we  cannot 
always  assume  that  a  problem  is  well-understood  and  that  clear  and 
precise  specifications  exist.  Various  examples  are  given  to  show 
that  in  this  case,  testing  is  needed. 

The  third  issue  is  the  ease  with  which  proofs  can  be  incorrect  by 
making  erroneous  assumptions.  Incorrect  understanding  of  the 
semantics  of  a  language,  of  the  operating  systems,  and  of  the 
hardware  are  aspects  of  this  issue.  Also  when  proving 
correctness,  there  is  a  reliance  on  mathematical  models,  that 
differ  from  reality  in  subtle  ways.  Thus  proofs  will  overlook 
such  pragmatic  features  as  round-off  errors,  storage  capacity 
limitations,  incorrect  interfaces,  and  timing  considerations. 

The  paper  concludes  that  testing,  which  is  based  on  the  actual 
performance  of  the  program,  does  not  suffer  from  the  false 
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illusions  exhibited  by  proofs.  Emphasis  is  placed  on  the  need  to 
educate  users  in  systematic  testing. 


THAYER75 

Thayer,  T.A.;  Understanding  Software  through  Empirical  Reliability 
Analysis;  AFIPS  Conference  Proceedings  44  (1975)  pp. 335-341. 

Recent  efforts  to  produce  reliable  software  have  involved  a 
variety  of  new  techniques  (e.g.,  structured  programming). 
However,  there  is  a  need  to  collect  and  analyze  data  on  the  value 
of  the  new  techniques.  This  paper  describes  an  effort  to  fulfill 
this  need  by  the  TRW  Systems  Group  for  the  Rome  Air  Development 
Centre.  Based  on  collected  data  on  errors  at  different  stages  of 
program  development,  it  is  possible  to  formulate  a  metric  for 
software  reliability.  The  author  points  out  that  expenditures  for 
data  collection  and  analysis  will  provide  a  payoff  in  improved 
reliability. 


THORPE76 

Thorpe,  A.J.L.;  Family  Programming  Teams;  Datamation  22,3  (March 
1976)  pp. 221-222,224. 

Unnecessary  problems  are  created  by  randomly  selecting  members  for 
a  Chief  Programmer  Team  from  a  pool  of  programmers.  These 
problems  are  solved  by  the  "family  team"  approach.  A  family  team 
is  a  group  of  programmers  who  remain  together  for  many  projects. 
There  may  be  occasional  changes  in  membership,  but  by  and  large 
the  team  remains  intact.  While  some  of  the  claims  for  the  family 
team  may  be  extravagant  (e.g.,  programming  productivity  will  be 
quadrupled!),  the  author  does  provide  some  good  reasons  for 
pursuing  such  an  approach. 


TRIVEDI75 

Trivedi,  A.K.,  and  Shooman,  M.L.;  A  Many-State  Markov  Model  for 
the  Estimation  and  Prediction  of  Computer  Software  Performance 
Parameters;  Proceedings  International  Conference  on  Reliable 
Software,  SIGPLAN  Notices  10,6  (June  1975)  pp. 208-220. 

The  authors  describe  a  many  state  two  parameter  Markov  process 
where  the  states  are  described  by  the  number  of  errors  detected 
and  solved  (up  state)  or  the  number  of  errors  detected  and  not 
solved  (down  state).  The  parameters  describe  the  rates  of  error 
discovery  and  repair.  They  then  derive  the  differential  equations 
and  solve  them  in  special  cases.  Unfortunately  no  study  is  given 
to  demonstrate  the  accuracy  (or  lack  thereof)  of  the  model. 


TSICHRITZIS73 

Tsichritzis,  D.;  Project  Management;  in  F.L.  Bauer  (ed.).  Advanced 
Course  on  Software  Engineering;  S pringer- Verlag,  New  York  (1973) 
pp. 374-384. 
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The  author  feels  there  are  two  main  reasons  for  difficulty  a 
managing  software  projects:  poor  management  (due  to  the  lack  of 
persons  with  both  adequate  technical  and  managerial  skills) ;  and 
the  frequent  changes  in  job  specification  and  personnel  that 
occur.  Tsichritzis  stresses  the  need  for  good  team  communication 
and  concludes  that  small  teams  (5-10  people)  are  the  best  aid  to 
communication.  The  three  main  phases  of  a  software  project  as  the 
author  views  them  are  outlined,  including  a  brief  example  from 
project  SUE  at  Toronto.  Finally,  Tsichritzis  discusses  the 
management  of  'large'  projects.  Here  again  he  questions  the  need 
for  a  'large'  project  and  advocates  instead  a  small  group  of 
highly  skilled  persons. 


TSUI 7  6 

Tsui,  F. ,  and  Priven,  I.;  Implementation  of  Quality  Control  in 
Software  Development;  AFIPS  Conference  Proceedings  45  (1976) 
pp. 443-449. 

A  software  development  paradigm  is  proposed  to  facilitate  the 
production  of  "high"  quality  software  with  minimum  error  rates  and 
low  costs.  Since  errors  in  a  final  product  are  expensive  to 
correct,  the  emphasis  is  on  the  early  detection  and  correction  of 
errors.  The  first  stage  in  the  paradigm  is  the  construction  of 
process  definitions.  The  authors  define  two  levels  of  design 
activity  (high-level  and  detailed)  and  three  categories  of  testing 
(functional,  component,  and  system) .  Unlike  a  modular  approach  in 
which  all  modules  are  constructed  separately  and  then  integrated 
at  the  end,  the  authors'  "Continuous  Integration"  is  an  iterative 
model  in  which  functions  are  added  individually  to  a  working  base 
and  tested.  Since  most  errors  have  been  previously  eliminated 
from  the  working  base,  new  errors  are  probably  in  the  newly  added 
function  or  the  interface.  Two  important  requirements  of  this 
model  are  a  system  blueprint  and  a  project  workbook. 


VAN  DU YN 72 

Van  Duyn,  J.;  Documentation  Manual;  Auerbach,  Philadelphia  (1972) 
pp. 1-158. 

This  is  a  compact  paperback  which  covers  documentation  of  data 
processing  systems.  The  book  is  organized  as  a  set  of  templates 
for  each  part  of  the  documentation  with  one  or  two  case  studies  to 
illustrate  each  section.  The  approach  is  rigid  and  is  profusely 
illustrated  with  forms,  charts,  and  tables.  The  author  does  not 
feel  it  necessary  to  justify  the  methods  presented,  since  they  are 
taken  from  practices  that  are  standard  and  widely  accepted,  at 
least  in  the  commercial  programming  field. 


VAN  TASSEL74 

Van  Tassel,  D.  ;  Program  Style ,  De  sign.  Efficiency ,  Debugging,  and 
Testing ;  Prentice-Hall  (1974)  pp. 1-256. 

This  is  a  good  introductory  textbook  for  programmers  who  want  to 
systematically  study  the  aspects  of  software  engineering  indicated 
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in  the  book's  title#  Throughout  the  book,  the  author  sees  the 
computer  program  primarily  as  an  entity  to  be  read  by  humans 
rather  than  by  the  machine.  Each  chapter  is  followed  by  numerous 
exercises  and  references.  Unfortunately,  many  of  the  references 
are  already  dated.  Programming  examples  are  in  the  "old" 
languages:  Fortran,  Cobol,  Algol,  and  PL/I. 

The  book  is  useful  as  a  programming  style  reference  manual  or 
checklist  for  the  advanced  high  level  language  programmer. 
However,  it  does  not  treat  topics  in  great  depth.  For  example, 
structured  programming  is  covered  in  less  than  five  pages! 

One  valuable  feature  of  the  book  is  the  chapter  on  program 
testing.  This  is  notable  because  with  a  few  exceptions  (e.g., 
Hetzel's  Program  Test  Methods  or  Yourdon's  Techniques  of  Program 
Structure  aji<f  Design)  ,  there  is  relatively  little  material  in 
other  books  on  the  topic  of  program  testing. 


W  ADSWORT  H7  3  CR26804 
Wadsworth,  M.D.;  The  Human  Side  of  Data  Processing  Management; 
Prentice-Hall  (1973)  pp. 1-244. 

The  text  is  intended  for  large  computer  installations  with  a  staff 
of  15  or  more,  however,  the  arguments  are  valid  for  any 
superior/subordinate  relationship. 

This  book  has  ten  chapters.  Chapter  one  presents  five  levels  of 
human  needs  (psychological,  security,  social,  esteem,  and  self- 
realization  or  achievement)  and  four  styles  of  leadership 
(authoritarian,  democratic,  laissez-faire,  and  buddy-buddy) .  To 
be  effective,  the  manager  must  learn  to  use  all  four  styles  of 
leadership.  Chapters  two  through  five  contain  15  case  studies 
illustrating  which  leadership  style  is  best  suited  to  satisfy  an 
identifiable  level  of  human  need  in  order  to  improve  individual 
performance.  The  checklists  to  identify  the  level  of  human  need 
are  excellent.  Chapters  six  through  eight  give  additional 
examples  to  improve  profitability  and  productivity  in  system 
development,  system  maintenance,  and  computer  operations 
respectively.  Chapter  nine  details  ways  to  improve  "user" 
acceptance,  cooperation,  and  involvement.  Chapter  ten  is  directed 
to  the  EDP  manager. 


WARD76 

Ward,  R.G.;  A  Non-Iterative  Situation  Case  Statement;  SIGPLAN 
Notices  11,7  (July  1976)  pp. 55-62. 

Dijkstra's  call  for  language  constructs  that  encourage  clear 
thinking  has  been  answered  by  many  proposals.  One  such  construct 
is  the  situation  CASE  statement.  It  has  been  described  in  both 
iterative  and  non-iterative  form  by  Zahn  and  Knuth.  The  author 
contends  that  the  non-iterative  situation  CASE  statements  proposed 
are  not  entirely  satisfactory  and  proposes  one  himself.  It  is  in 
the  form  of  a  compound  WHEN  statement  with  several  situation 
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selectors  and  statements.  Examples  show  that  this  construct  could 
easily  take  the  place  of  complicated  IF_THEN_ELSE  type  constructs. 


WARREN75 

Warren,  J.C.,  Jr.;  Software  Portability:  A  Survey  of  Approaches 
and  Problems;  IEEE  COMPCON,  Spring  1975  (February  1975)  pp.253- 
256. 

In  this  paper  the  author  outlines  the  pertinent  concepts, 
advantages  and  disadvantages  of  portable  software.  The  different 
approaches  that  have  been  used  are  presented  along  with  reference 
examples  of  each  method.  The  paper  includes  a  major  discussion  of 
portability  via  high  level  languages,  and  via  abstract  machines 
and  pseudo-codes.  The  conclusion  outlines  some  approach- 
independent  problems  and  suggests  a  number  of  areas  in  which 
research  is  needed.  The  paper  includes  a  large  list  of 
references. 


WASSERMAN75 

Wasserraan,  A. I.;  Issues  in  Programming  Language  Design  --  An 
Overview;  AFIPS  National  Conference  Proceedings  1975  pp. 297-299. 

A  summary  of  the  developments  (and  the  reasons  for  them)  in 
programming  language  design.  The  objectives  of  design  are 
discussed  and  definitions  and  descriptions  of  the  main  areas  of 
research  are  given.  Three  fundamental  questions  which  the  author 
believes  underlie  the  current  research  and  development  are  given 
as  a  conclusion.  This  is  a  very  comprehensible  article  covering 
many  aspects  of  design,  and  could  serve  as  a  useful  consolidation 
of  knowledge,  or  as  a  very  good  introduction  to  the  area.  An 
extensive  list  of  references  is  provided. 


WATKINS73 

Watkins,  R.P.;  Towards  a  Theory  of  Documentation;  The  Australian 
Computer  Journal  5,2  (May  1973)  pp. 57-61. 

An  advance  is  made  toward  the  theory  of  documentation  by  the 
definition  of  intensional  documentation,  extensional 

documentation,  and  level  of  detail.  This  provides  a  formal 
statement  of  the  structure  of  documentation.  The  statement  not 
only  matches  the  current  intuitive  concepts,  but  gives  a  deeper 
insight  into  the  reasons  for  and  values  of  these  structures. 


WEGBREIT76 

Wegbreit,  E. ;  Verifying  Program  Performance;  JACM  23,4  (October 
1976)  pp. 691-699. 

The  author  approaches  the  problem  of  verifying  program  performance 
rather  than  correctness.  In  this  approach,  assertions  are  given 
regarding  the  probabilities  of  certain  data  structurings  or 
program  performances.  Using  verification  rules  which  are  similar 
to  those  used  in  Hoare's  axiomatic  system,  such  things  as  the  mean 
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number  of  times  through  a  loop  may  be  determined  given  the  proper 
assertion  and  invariants.  One  of  the  interesting  aspects  of  this 
approach  is  that  given  a  probability  based  formula  for  a  loop 
invariant,  not  only  the  fact  that  the  invariant  is  true  on  exit 
from  the  lcop  is  important,  but  also  that  it  is  true  at  each 
iteration  since  the  values  of  the  invariant  at  each  iteration  give 
probabilities  of  such  things  as  "is  the  array  sorted"  or  "will  the 
loop  exit  this  time".  A  familiarity  with  axiomatic  proof  systems 
(such  as  Hoare's)  is  assumed  by  the  author. 


WEINEERG72 

Weinberg,  G.M.;  The  Psychology  of  Improved  Programming 

Performance;  Datamation  18,11  (November  1972)  pp. 82-85. 

In  this  article  Weinberg  reports  on  an  experiment  to  test  the 
impact  of  goals  on  programming  performance.  The  importance  of 
explicitly  stated  goals  is  stressed  by  noting  their  large  impact 
not  only  on  the  programs,  but  also  on  estimates.  Most  interesting 
and  useful  was  the  observation  that  "programs  built  under 
promptness  objectives  can  be  significantly  improved  in  almost  all 
other  objectives,  while  programs  built  under  minimum  core  or 
maximum  efficiency  tend  to  be  less  elastic."  Weinberg  concludes 
by  suggesting  the  adoption  of  an  'analysis-coding-debugging- 
improving  '  strategy. 


WEINBERG7  5 

Weinberg,  G.M.,  Geller,  D.P.,  and  Plum,  T.  W-S;  IF-THEN  - ELS  E 
Considered  Harmful;  SIGPLAN  Notices  10,8  (August  1975)  pp. 34-44. 

The  authors  are  not  against  the  IF-THEN-ELSE  construct  in  all 
cases,  but  rather  the  unrestricted  nesting  of  the  control 
structure,  which  they  claim  can  lead  to  undesirable  programs.  The 
major  problem  with  IF-THEN-ELSE  logic  is  the  inability  of  the 
human  mind  to  understand  nested  constructs.  Thus,  the  authors 
advocate  the  use  of  replicated  forms,  giving  English  language 
examples  to  illustrate  their  point  that  regularity  allows  a  person 
to  understand  this  form  more  easily.  Three  replicated  forms  are 
suggested,  and  specific  examples  are  given.  The  article  stresses 
the  perils  of  a  one-to-one  translation  from  IF-THEN-ELSE 
constructs  to  replicated  forms,  claiming  that  the  'naturalness'  of 
the  form  must  be  exploited  in  order  to  derive  full  benefits. 


WELLER  73 

Weller,  M.F.;  Report  of  Session  on  Transferability;  SIGPLAN 
Notices  8,9  (September  1973)  pp. 11-16. 

The  report  discusses  two  aspects  of  portability  "Today's 
Transferability  Problems"  and  "Future  Systems  Design  for 
Transferability."  Short  discussions  are  given  on  the  following 
aspects  cf  portability:  emulation,  standardization  and 

consideration  of  an  operating  systems  interface  as  an  abstract 
machine.  Similarly  various  opinions  are  given  for  the  future 
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design  to  improve  portability  such  as  extensible  languages, 
stressing  flexibility  and  levels  of  transferability. 


WELLS73 

Wells,  M.B.;  Algorithmic  Languages  and  Machine-Oriented  Tasks; 
Proceedings  of  the  IFIP/TC2  Conference  on  Machine-Oriented  High- 
Level  Languages  (August  1973). 

The  author  summarizes  a  theme  of  the  paper  when  he  states  "This 
author  believes  that  there  is  much  less  that  is  peculiar  to 
systems  programming  than  many  people  believe."  He  argues  that  the 
term  high-level  should  imply  small,  algorithmic,  machine- 
independent  languages.  He  further  claims  that  the  attempt  to 
control  the  implementation  details  is  the  cause  of  implementation 
languages  being  massive  and  complex. 

To  solve  the  technical  difficulties  of  efficient  compilation,  he 
suggests  that  we  study  compiler  and  hardware  design  as  seperate 
problems.  Moreover,  we  should  restrict  ourselves  to  subsets  of 
algorithmic  languages  for  which  efficient  compilers  can  be 
written. 


WHEELER  72 

Wheeler,  D.J.;  Assessing  the  Complexity  of  Computer  Systems; 
Proceedings  of  IFIP  Congress  71  (1972)  pp. 541-544. 


WIRTH73 

Wirth,  N;  Systematic  Progra mming :  an  Introduction ;  Prent ice- Hall, 
Inc.,  Englewood  Cliffs,  N.J.  (1973)  pp. 1-169. 

This  book  introduces  programming  as  the  art  or  technique  of  of 
constructing  algorithms  in  a  systematic  manner,  as  a  discipline  in 
its  own  right.  No  specific  area  of  application  is  emphasized. 
This  book  is  tailored  to,  the  needs  of  people  who  view  a  course  on 
systematic  programming  as  a  (possibly  neglected)  part  of  basic 
mathematical  training.  Few  people  beside  Dijkstra  will  fail  to 
profit  from  reading  it. 


WIRTH74 

Wirth,  N.;  On  the  Composition  of  Well-Structured  Programs; 
Computing  Surveys  6,4  (December  1974)  pp.  247-259. 

Wirth  laments  that  "the  same  inertia  that  kept  many  assembly  code 
programmers  from  advancing  to  use  FORTRAN  is  now  the  principal 
obstacle  against  moving  from  a  FORTRAN-like  style  to  a  structured 
style."  For  those  who  are  eager  to  advance,  Wirth  presents 
several  examples  illustrating  the  use  of  stepwise  refinement  to 
achieve  "well  structured  programs."  The  use  of  different  levels 
of  abstraction  to  achieve  good  structure  is  advocated. 

Wirth  concludes  by  stating  that  the  use  of  FORTRAN,  "an 
unstructured  language...  to  teach  programming  —  the  art  of 
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systematically  developing  algorithms  —  can  no  longer  be  defended 
in  the  context  of  Computer  Science  education." 


WIRTH75 

Wirth,  N.;  An  Assessment  of  the  Programming  Language  Pascal; 
Proceedings  International  Conference  on  Reliable  Software,  Los 
Angeles,  SIGPLAN  Notices  10,6  (June  1975)  pp. 23-30. 

In  his  lengthy  introductory  remarks,  the  author  uses  a  variety  of 
non-programming  illustrations  to  suggest  that  the  adjective 
"reliable"  should  be  replaced  by  "correct"  when  describing  a 
computer  program.  Compared  to  reliability,  correctness  can  be 
easily  identified  and  measured. 

The  paper  provides  a  description  of  some  of  the  constructs  of 
Pascal  that  promote  the  production  of  correct  programs.  A 
distinguishing  feature  of  the  constructs  is  that  they  provide  the 
redundancy  necessary  for  error  detection.  Some  features  of  Pascal 
do  not  facilitate  correctness.  These  include  the  rules  for 
operator  precedence,  the  GOTO,  and  file  handling. 


WOLVERTON  74 

Wolverton,  R.W.;  The  cost  of  developing  Large-Scale  Software;  IEEE 
Transactions  on  Computers  C-23,6  (June  1974)  pp. 615-636. 

This  paper  gives  a  short  precis  of  a  tremendous  quantity  of 
information  gathered  by  the  author  over  many  years  on  project  cost 
estimation.  What  is  presented  is  a  somewhat  formal  methodology  of 
cost  estimation. 

The  methodology  is  based  on  a  matrix  scheme,  where  a  cell  of  the 
matrix  represents  the  cost  of  activity  of  a  particular  nature  at  a 
certain  phase  in  the  project.  The  various  phases  and  activities 
are  presented  explicitly  along  with  figures,  taken  from  projects 
the  author  has  taken  part  in,  citing  probable  costs. 

One  of  the  keys  to  the  estimation  of  cost,  the  author  claims,  is 
comparison  with  previous  projects.  A  data  base  containing  actual 
cost  statistics  in  specified  areas  of  projects  isrecommended  as  a 
valuable  tool. 

This  methodology  has  arisen  partially  because  of  the  stringent 
contract  specifications  that  (U.S.)  government  software  is 
produced  under.  The  government  is  very  concerned  about  cost/time 
overruns  and  insists  on  highly  accurate  cost  estimation. 


WOLVERTON  75 

Wolverton,  R.W.;  The  Cost  of  Developing  Large  Scale  Software;  in 
Horowitz,  E.  (ed . ) ,  Practical  Strategies  for  Developing  Large 
Software  Systems;  Add ison-Wesley  (1975)  pp. 73-100. 

On  the  basis  of  a  thorough  study  of  the  process  of  software 
development,  reasonable  guidelines  for  costing  large-scale 
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software  have  been  produced.  The  author  describes  a  complete 
algorithm  for  software  cost  estimation.  A  data  base  for  cost 
justification  to  the  customer  is  also  described.  While  he  does 
provide  a  detailed  description  of  costing,  the  author  recognizes 
and  identifies  some  of  the  key  issues  in  cost  estimation  that 
reguire  further  research. 


WOODGER72  CR24,757 

Woodger,  M.;  On  Semantic  Levels  in  Programming;  Proceedings  of 
IFIP  Congress  71  (1972)  pp. 402-407. 

This  paper  discusses  the  recognition  of  levels  of  meaning  in 
relation  to  the  programming  of  a  solution  to  a  given  problem.  An 
analogy  with  the  ’’operating  manual"  of  a  machine  is  made  in  an 
attempt  to  expose  inadequacies  in  present  programming  practice. 
The  authcr  maintains  that  at  each  level  an  abstraction  of  a 
process  (whose  meaning  is  clear  without  reference  to  the  other 
levels)  must  be  made.  Finally,  he  argues  that  conventional 
programming  practices  tend  to  confuse  these  levels,  and  that 
subroutines  do  not  solve  the  problem. 


W0RTMAN72  CR25,416 
Wortman,  D.B.;  A  Study  of  La nguage -Di rected  Computer  Design; 
Technical  Report  20,  Computer  Systems  Research  Group,  University 
of  Toronto  (December  1972)  pp. 1-207. 

Starting  with  a  "clean"  subset  of  PL/I,  the  author  designs  a 
computer  to  implement  its  semantics  directly.  He  then 
analyzes/predicts  its  performance,  and  in  the  process  develops 
tools  which  "could  also  be  used  by  the  programmer  to  evaluate  the 
performance  of  computers."  This  turns  out  to  be  the  major  useful 
part  of  the  work,  because,  as  he  points  out,  "for  languages  with  a 
less  elegant  structure  the  design  problem  is  much  more  difficult." 


WULF72a 

Wulf,  W.A.;  The  GOTO  Controversy:  A  Case  Against  the  GOTO;  SIGPLAN 
Notices  7,  11  (November  1972)  pp. 63-69. 


WULF7  2b 

Wulf,  W.A.,  Hopkins,  M.E.,  Peterson,  W. W. ,  and  Waite,  W.M.;  The 
GOTO  Controversy:  Rebuttals  and  Discussion;  SIGPLAN  Notices  7, 
11  (November  1972)  pp. 70-91. 


WULF 72c  CR2  4, 7  1  7 

Wulf,  W.A.;  Programming  Without  The  GOTO;  Proceedings  of  IFIP 
Congress  71  (1972)  pp. 408-413. 

In  this  article  the  author  explores  the  common  program 
constructions  and  shows  how  they  may  be  realized  without  goto 
statements.  He  then  describes  his  own  experience  with  the 
language  BLISS,  which  is  goto-less.  He  concludes  that: 
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(1)  It  does  not  matter  whether  or  not  a  language  includes  the 
goto.  There  are  certain  types  of  control  flow  which  occur  in  real 
programs.  If  these  constructs  are  not  provided  then  gotos  should 
be  used  to  synthesize  them.  The  danger  of  gotos  is  that  the 
programmer  will  do  this  in  obscure  ways. 

(2)  The  advantage  in  eliminating  the  goto  is  that  these  same 
control  structures  will  appear  in  regular  and  well-defined  ways. 
Both  the  human  and  the  compiler  will  interpret  them  better. 


WULF73 

W  ulf ,  W.  ,  and  Shaw,  M.  ;  Global  Variable  Considered  Harmful; 
SIGPLAN  Notices  8,2  (February  1973)  pp. 28-34. 

An  extension  of  Dijkstra's  arguments  against  GOTO's  to  global 
variables  -  variables  defined  and  modified  over  large  portions  of 
text.  Argues  for  richer  methods  of  defining  variable  scope  than 
the  Algol  block-structured  approach.  E. g. ,  one  should  be  able  to 
limit  access  to  stacks  and  pointers  to  push-pop  routines  only . 

The  authors  argue  that  (a)  keeping  track  of  global  variables  is 
difficult,  and  (b)  global  variables  complicate  the  process  of 
figurirg  out  what  a  program  segment,  whose  actions  depend  on  them, 
does. 

The  authors  point  out  that  the  problem  is  not  so  simple  as  the 
GCTO  problem,  since  (a)  there  is  no  "single  offending  construct," 
and  (b)  there  are  no  accepted  alternatives  which  avoid  it. 
Criteria  for  alternatives  are  presented,  but  no  examples  are 
provided. 


WULF75 

Wulf,  W.A.;  Reliable  Hardware/Software  Architecture;  IEEE 
Transactions  on  Software  Engineering  SE-1,2  (June  1975)  pp.233- 
240. 

A  presentation  of  the  handling  of  (particularly  hardware)  errors 
in  the  Hydra  operating  system  which  handles  the  interaction  of 
sixteen  mini-computers.  This  paper  deals  particularly  with  those 
errors  which  could  occur  in  a  program  which  has  been  verified, 
such  as  parity  checks,  I/O  errors  etc.  Hydra  attempts  to  make 
these  errors  transparent  to  the  user  where  possible  and  otherwise 
attempts  to  inform  the  user  of  the  error  politely.  The  basic 
modular  structure  of  Hydra  and  how  the  errors  are  handled  or 
propagated  by  these  modules  is  discussed. 


Y0HE74 

Yohe,  J.M.;  An  Overview  of  Programming  Practices;  Computing 
Surveys  6,4  (December  1974)  pp. 221-245. 

According  to  the  author,  the  purpose  of  this  paper  is  to  outline 
something  of  the  nature  of  "good  programming."  Since 
communication  between  humans  is  just  as  important  as  communication 
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with  the  computer,  the  concept  of  programming  entails  adequate 
documentation  and  certain  other  tasks  to  be  performed.  The  author 
divides  the  programming  process  into  nine  tasks  and  discusses  each 
of  them.  The  paper  is  directed  to  students  or  beginning 
programmers,  but  does  not  exclude  experienced  programmers. 

The  difference  between  coding  and  programming  is  stressed  early  on 
in  the  paper,  when  he  separates  their  two  functions  into  program 
writing  and  design  analysis.  The  author  later  concludes  that 
•'coders  are  not  difficult  to  find,  but  a  truly  good  programmer 
is." 


YOURDON75 

Yourdon,  E.;  Techniques  of  Program  Structure  and  Design;  Prentice- 
Hall  (1975)  pp. 1-364. 

This  book  provides  a  good  coverage  of  recent  concerns  in  the  field 
of  software  engineering.  It  makes  numerous  references  to  the 
"prophets"  (Bohm,  Jacopini,  Dijkstra,  Wirth,  Weinberg) .  The 
inclusion  of  many  problems  makes  it  useful  as  a  textbook.  The 
inclusion  of  references  (some  as  recent  as  1974)  make  the  work 
useful  as  a  basic  reference  book. 

While  the  title  may  suggest  that  the  book  is  another  style  manual, 
the  author  places  great  emphasis  on  the  philosophy  of  programming 
before  embarking  on  descriptions  of  techniques.  Three  separate 
chapters  are  devoted  to  the  philosophies  of  top-down  program 
design,  modular  programming,  and  structured  programming.  In  the 
latter,  there  is  an  interesting  section  on  the  conversion  of 
unstructured  programs  to  structured  ones. 

It  is  significant  that  there  is  no  chapter  on  "Efficiency".  The 
emphasis  throughout  the  book  is  not  on  efficient  coding,  but 
rather  correct,  readable  programs. 

As  well  as  a  chapter  on  debugging,  the  author  includes  one  on 
"antibugging"  (defensive  programming) .  The  chapter  is  a  plea  for 
the  use  of  programmed  error  checks.  Since  there  is  relatively 
little  literature  on  the  subject,  the  chapter  on  program  testing 
is  a  valuable  feature  of  this  book. 


ZAHN75 

Zahn,  C.T.;  Structured  Control  in  Programming  Languages;  SIGPLAN 
Notices  10,7  (July  1975)  pp. 13-15. 

A  major  goal  of  programming  language  design  should  be  the 
reduction  of  the  "conceptual  distance"  between  problem  definition 
and  program  text.  This  goal  will  be  better  realized  with  some 
compromise  in  the  restricted  controls  imposed  by  structured 
programming.  Zahn  cites  a  variety  of  instances  in  which  problem 
oriented  control  statements  involve  considerably  less  conceptual 
distortion  than  structured  programming  statement.  Thus  an 
important  programming  design  consideration  should  be  the  provision 
of  certain  problem  oriented  control  statements. 
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ZELKO  WITZ74 

Zelkowitz,  M.V.,  and 
Programs;  Software 
pp. 5 1- 57. 


CP27,034 

Bail,  W.G.;  Optimization  of  Structured 
Practice  and  Experience  4,1  (January  1974) 


A  code  optimizer  for  a  procedure-oriented,  'goto-less*  language, 
SIMPL,  is  described.  The  char act erist ics  of  structured  programs 
are  used  to  eliminate  redundant  subexpressions  and  loop  invariant 
calculations.  However,  the  results  obtained  indicate  only  a 
slight  decrease  in  program  size  (no  compile-time  or  execution-time 
figures  are  presented).  The  authors  list  possible  refinements  to 
the  optimizer;  they  also  suggest  that  perhaps  programs  written  in 
a  structured  programming  language  do  not  require  a  separate 
optimization  phase. 


-88- 


Part  3 


Older  Articles 


A  EE A MS 70  CR20,828 
Abrams,  P.S.;  An  APL  Machine;  Clearinghouse,  U.S.  Department  of 
Commerce,  Springfield,  Virginia  (February  1970)  pp. 1-204. 


ALEX A  NDER7 1 

Alexander,  W.G.;  How  a  Programming  Language  is  Used;  Technical 
Report  10,  Computer  Systems  Research  Group,  University  of  Toronto 
(February  1972)  pp. 1-119. 

An  analysis  tool  is  discussed  and  developed  with  which  an  XPL 
programmer  may  determine  the  status  and  dynamic  usage  of  time  and 
the  distribution  of  machine  instruction  usage  for  his  XPL  program. 
Although  limited  in  its  scope  to  one  language  it  is  a  good  example 
of  the  type  of  low  level  analysis  technique  that  could  profitably 
be  applied  to  any  large  programming  project  to  pinpoint 
unsuspected  inefficiencies.  The  particular  implementation  used  is 
slow  because  it  relies  upon  operating  system  interrupts  and 
recoveries  but  does  produce  comprehensive  (although  not 
selectively  controlled)  data  analysis. 


ALLEN71  CR2  2,683 
Allen,  C.D.;  The  Application  of  Formal  Logic  to  Programs  and 
Programming;  IBM  Systems  Journal  10,  1  (January  1971)  pp.2-38. 

A  hierarchical  application  of  first-order  predicate  calculus  is  a 
practical  solution  for  proving  the  correctness  cf  programs.  Allen 
first  gives  a  brief  introduction  to  formal  logic,  and  then 
develops  the  results  of  Manna  and  Ashcroft  on  an  elementary  level. 
Finally  he  presents  some  examples  and  theories  of  his  own  as  well 
as  some  applications  of  the  proof  techniques. 


ARBEN69 

Arden,  B.W.,  and  Boettner,  D. ;  Measurement  and  Performance  of  a 
Multiprogramming  System;  Proceedings  ACM  Second  Symposium  on 
Operating  Systems  Principles  (October  1969)  pp. 130-146. 


ASHCROFT71  CR21,940 
Ashcroft,  E.A.,  and  Manna,  Z.;  Formalization  of  Properties  of 
Parallel  Programs;  Machine  Intelligence  6,  Edinburgh  University 
Press  (1971)  pp. 17-42. 

This  paper  provides  a  very  instructive  introduction  to 
possibilities  for  applying  formal  proof  techniques  to  parallel 
programs.  The  first  section  consists  of  a  definition  of  what  will 
be  considered  a  parallel  program:  it  may  contain  simple 
assignment  statements,  test  statements,  (possibly  recursive) 
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process  calls,  and  blocks  defining  parallel  branches.  In  this 
context  the  properties  of  a  "computation, "  and  the  possible  ways 
of  terminating  parallel  segments  are  discussed. 

It  is  shown,  by  example,  how  a  parallel  program  may  be  transformed 
into  a  non-determinist ic  program,  which  is  the  basis  for  the 
desired  formalization.  Also  presented  at  this  stage  are  the 
possible  ways  of  defining  "protected1'  sections  of  programs,  which 
are  required  for  the  subsequent  simplification  methods. 

Properties  which  programs  may  have  are  enumerated,  and  the  stages 
in  the  development  of  a  formal  statement  of  the  properties  of  a 
program  are  explained,  using  a  specific  example. 

The  last  major  section  describes  methods  for  program 
simplification,  based  on  the  detection  of  instances  in  which  the 
computation  of  a  program  is  independent  of  the  sequence  of 
execution  cf  parallel  segments,  thus  reducing  the  total  number  of 
cases  for  which  formulae  must  be  derived. 

The  paper  concludes  with  suggestions  of  additional  program 
features  which  might  be  considered  in  similar  fashion. 


BALZER67  CR15,184 

Balzer,  R.M.;  Dataless  Programming;  Proceedings  of  the  FJCC  31 
(1967)  pp. 535-544. 


BEIADY71 

Belady,  L.A.,  and  Lehman,  M.M.;  Programming  System  Dynamics  or  the 
Meta-Dynamics  of  Systems  in  Maintenance  and  Growth;  IBM  Research 
Center,  Ycrktown  Heights,  no.  RC3456  (September  1971). 

A  model  is  developed  for  large  programming  systems  in  which 
continuous  repairs  and  enhancements  occur.  This  primary  effort 
leads  to  fragmentation  of  the  system  and  of  the  repairs  and 
enhancements,  and  is  shown  to  be  linearly  bounded  by  cost. 
However,  a  secondary  and  exponential  effort  shows  up  because  of 
correlation  between  fragments,  communications  among  others  working 
in  parallel,  and  maintenance  of  documentation.  There  is 
initially,  in  practice,  a  decay  in  the  secondary  effort  due  to  the 
initial  accuracy  and  correctness  of  the  system;  however,  the 
authors  believe  this  is  only  temporary  in  nature,  i.e.,  the  effort 
to  maintain  the  resultant  work  is  itself  always  exponential  due  to 
the  same  factors. 

By  identifying  these  linkages  of  communications  and  maintenance  as 
critical  points  the  authors  feel  that  a  "programming  system 
development  nrethodology, "  which  includes  the  elimination  of  global 
variables  and  adopting  unspecified  but  reasonable  standards  of 
documentation,  is  essential.  Since  they  believe  the  exponential 
term  never  vanishes,  their  objective  is  to  delay  the  explosive 
cost  growth  of  maintaining  large  systems.  As  a  result  the  present 
requirement  is  "to  quantify  complexity  of  growth  measures...  to 
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plan  precisely  for  the  development,  maintenance,  growth  and 
ultimate  termination  of  a  system,  and  its  replacement." 


BRINCH  HANSEN70  CR19,620 
Brinch  Hanses,  P.;  The  Nucleus  of  a  Multiprogramming  System;  CACM 
13,4  (April  1$10)  pp. 238-241, 250. 


DROP HY70  CR20 ,23  1 

Brophy,  H.F.;  Improving  Programming  Performance;  Australian 
Computer  Journal  2,2  (May  1970)  pp. 66-70. 


"The  purpose  of  this  paper  is  to  shift  the  spotlight  onto  the 
human  element  of  this  man/machine  relationship."  In  this  article, 
Brophy  discusses  ways  of  increasing  programming  performance,  as 
opposed  to  building  bigger  and  better  machines.  To  achieve  an 
improvement,  he  suggests  the  use  of  better  tools,  the  better  use 
of  already  available  tools,  and  the  imposition  of  standards. 
Generalized  systems  are  suggested  that  will  avoid  needless 
reprogramming  to  solve  a  variation  of  a  previously  solved  problem. 

the  use  of  decision  logic  tables,  more  comments, 
variable  names,  better  documentation  cross 

the  program,  and  the  use  of  programming  teams  as 
utilizing  the  existing  tools  of  software 

Finally,  standards  in  language,  data  structures, 
etc.,  are  proposed  to  improve  communication  between 


Erophy  suggests 
more  meaningful 
referenced  with 
ways  of  better 
development, 
documentation. 


different  programming  groups  and 
computer  software. 


to  improve  the  portability  of 


BRGWN71  CR23  ,004 

Brown,  F.D.,  Calderbank,  V.J. ,  and  Poole,  M. D. ;  Some  Comments  on 
the  Portability  of  a  Large  ALGOL  Program  -  The  Implementation  of 
SID  on  KDF 9 ;  Software  -  Practice  and  Experience  1,4  (October- 
December  1971)  pp. 367-371. 

In  this  paper  the  authors  described  their  task  of  moving  a  large 
program,  SID,  written  in  ALGOL,  to  a  new  machine,  KDF9.  For  doing 
this,  four  major  difficulties  were  considered:  (1)  Is  the  task 
performed  by  the  program  independent  of  the  environment?  (2)  Is 
the  language  of  the  program  a  subset  of  the  dialects  accepted  by 
both  ALGOL  compilers,  and  do  these  compilers  interpret  this  subset 
identically?  (3)  Does  the  program  satisfy  all  the  quantitative 
constraints  imposed  by  the  target  compiler?  (4)  Is  a  conversion  of 
hardware  representation  necessary,  if  so,  is  it  a  trivial 
operation? 


BURST ALL  69a  CR17,495 

Burstall,  R.M.;  Proving  Properties  of  Programs  by  Structural 
Induction;  The  Computer  Journal  12,  1  (February  1969)  pp. 41-48. 

This  paper  presents  the  technique  of  structural  induction  for 
proving  the  validity  of  the  type  of  programs  where  repetition  is 
accomplished  by  recursion,  and  jumps  and  assignment  are  avoided. 
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The  author  considers  the  technique  of  structural  induction  a  very 
powerful  tool  which  is  easy  to  use  and  gives  a  clear  explanation 
in  ordinary  mathematical  terms  of  why  a  program  works  as  it  does. 
The  technique  depends  on  the  structure  of  the  data  manipulated  by 
the  program,  and  the  objective  is  to  prove  not  just  that  the 
program  works  for  specimen  input  data  but  that  it  will  work  in 
general  for  any  input  data. 

The  author  feels  that  the  first  step  should  be  to  devise  methods 
of  proof  of  validity  of  non-trivial  programs  in  a  comprehensible 
manner.  The  reasoning  might  later  be  formalized  to  a  point  where 
it  can  be  performed  by  a  computer  to  provide  mechanized  debugging 
aids. 

The  main  aim  of  the  paper  is  to  suggest  some  syntactic  devices  for 
writing  programs  in  a  way  which  facilitates  the  derivation  of 
proofs  by  structural  induction.  The  form  of  these  proofs  would 
then  be  similar  to  that  of  the  corresponding  programs.  The  author 
believes  that  the  discipline  of  stating  theorems  and  devising 
proofs  will  greatly  improve  programming  education  and  practice. 


BURSTALL69b 

Burstall,  R.M.,  Landin,  P.J.;  Programs  and  their  Proofs:  an 
Algebraic  Approach;  in  MeltzerfB.#  Michie,D.  (eds.),  Machine 
Intelligence  4,  American  Elsevier  Publishing  Co.  (1969)  pp. 17-43. 

An  excellent  introduction  for  someone  interested  in  the  algebraic 
techniques  cf  proving  program  correctness.  The  first  half  of  the 
paper  presents  all  the  algebraic  background  necessary  for  the 
actual  development  of  the  proofs  in  the  final  section.  Many  small 
examples  are  given  as  the  techniques  are  presented.  The  paper 
ends  with  a  proof  of  a  small  compiler  that  compiles  arithmetic 
expressions.  A  good  preparation  for  later  papers  on  the  same 
subject. 


B0XTON70 

Buxton,  J.N.,  and  Randall,  B.  (ed.);  Software  Engineering 
Techniques;  NATO  Scientific  Affairs  Division,  Brussels,  Belgium 
(1970)  pp. 1-164. 

This  publication  is  organized  in  two  parts:  first,  transcripts  of 
discussions  among  the  participants  of  the  conference;  and  second, 
a  collection  of  working  papers  presented  at  the  conference.  The 
emphasis  throughout  is  on  the  technical  aspects  of  real  problems 
rather  than  theoretical  or  management  techniques. 

Among  the  central  topics  of  discussion  are  software  quality  and 
flexibility,  the  problems  of  large  program  design  and 
implementation,  and  software  engineering  education.  Some 
interesting  highlights  are  the  discussion  of  the  Apollo  space 
program  from  the  computing  point  of  view  and  the  findings  of  IBM 
in  their  "super  programmer"  experiment. 
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The  papers  examine  specific  problem  areas  including  portability, 
software  reliability  and  software  evaluation.  This  publication 
presents  an  excellent  summary  and  discussion  of  the  problems  of 
software  engineering.  The  following  papers  are  included: 

Aron,  J.D.;  Estimating  Resources  for  Large  Programming  Systems 
Brown,  W.S.;  Software  Portability 
Dijkstra,  E.W.;  Structured  Programming 
Falkoff,  A.D.;  Criteria  for  a  System  Design  Language 
Gotlieb,  C.C.,  and  MacEwan,  G.H.;  System  Evaluation  Tools 
Hopkins,  M.E. ;  Computer  Aided  Software  Design 
Lang,  C. A. ;  Languages  for  Writing  System  Programs 
Needham,  R.M.;  Software  Engineering  Techniques  and  Operating 
System  Design  and  Production 

Needham,  R.M.,  and  Aron,  J.D.;  Software  Engineering  and 
Computer  Science 

Schwartz,  J.D.;  Analyzing  Large-Scale  System  Development 
Teitleman,  W.  ;  Toward  a  Programming  Laboratory 

Ulrich,  W. ;  Design  of  a  High  Reliability  Continuous  Operation 
System 


BUXT0N71 

Buxton,  J.N.;  The  Nature  and  Implications  of  Software  Engineering; 
in  Hugo,  J.S.  (ed) ,  The  Fourth  Generation,  Infotech,  Ltd., 
Berkshire,  England  (1971)  pp. 227-238. 

In  this  paper,  Buxton  attempts  to  make  clear  what  software 
engineering  is,  by  first  trying  to  define  computer  science,  and 
then  by  explaining  how  software  engineering  differs  from  it. 
Secondly,  he  discusses  the  essential  nature  of  software 
engineering. 


CCNST ANTINE68  CR14,168 
Constantine,  L.L.;  The  Programming  Profession,  Programming  Theory, 
and  Programming  Education;  Computers  and  Automation  17,2  (February 
1968)  pp. 14-19. 

The  classic  challenge  of  programming  has  been  that  it  lacks  (1)  an 
ordered  body  of  knowledge,  (2)  active  interaction  between  the 
practitioners  in  the  field  and  that  body  of  knowledge  and  (3)  a 
systematic  educational  approach  for  imparting  that  knowledge  to 
new  entrants  in  the  field.  The  author  maintains  that  the  body  of 
knowledge  of  programming  exists,  but  not  in  an  integrated  form. 
He  proposes  two  theories  distinct  from  each  other,  the  theory  of 
programs  and  the  process  theory  of  programming. 

Programs  consist  of  a  set  of  ordered  statements.  There  is  a 
structure  to  programs  determined  by  the  relation  of  the 
statements.  Programming  is  a  process  that  involves  human 
creativity.  Nevertheless,  it  is  governed  by  rules,  perhaps 
informal,  that  are  usually  followed.  Much  more  is  known  about 
programs  and  programming  than  is  being  taught.  The  problem  is  that 
most  of  the  knowledge  is  gained  in  industry  and  most  of  the 
teaching  is  being  done  in  the  universities.  The  author  maintains 
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that  a  lack 
results  in 
education, 
situation. 


of  communication  between  industry  and  the  universities 
the  computer  scientist  obtaining  an  incomplete 
He  proposes  a  program  that  is  intended  to  remedy  this 


CONWAY63 

Conway,  M.E.;  Design  of  a  Separable  Transition  Diagram 
C ACM  8,7  (July  1963)  pp. 396-408. 


CR  5 ,02  4 
Comp iler ; 


CCNWAY68 

Conway,  M.E.;  How  Do  Committees  Invent?;  Datamation  14,  4  (April 

1968)  pp. 29-32. 


C0RBAT069  CR1 7,694 
Corbato,  F.J.;  PL/I  as  a  Tool  for  System  Programming;  Datamation 
15,5  (May  1969)  pp. 68-76. 

One  of  the  more  important  aspects  of  the  MOLTICS  effort  was  the 
decision  to  use  PL/I  as  the  systems  implementation  language.  This 
paper  discusses  the  reasons  for  choosing  a  high  level  language  for 
systems  programming  and  the  reasons  why  PL/I  in  particular  was 
chosen  for  MULTICS.  The  difficulties  of  implementing  the  language 
and  some  of  the  evils  of  PL/I  in  such  an  environment  are 
discussed.  That  Honeywell  intends  to  make  the  system  commercially 
available  attests  to  either  the  correctness  of  their  assumptions 
or  extreme  perseverence  in  the  face  of  adversity. 


COX7  1 

Cox,  P.R.;  Machine  -  Independent  Operating  Systems:  A  Functional 
Approach  To  Design;  in  Hugo,  J.S.  (ed.).  The  Fourth  Generation, 

Infotech,  Ltd.  (1971)  pp. 239-258. 

The  term  operating  system,  as  currently  used  in  the  computer 
industry,  is  virtually  undefinable.  There  is  a  large  set  of 
functions  that  nearly  all  operating  systems  do  perform,  but  this 
set  is  inclined  to  become  a  little  fuzzy  around  the  edges. 

In  this  paper,  Cox  attempts  to  set  forth  objectives  that  are 

reguired  in  a  machine  -  independent  operating  system  and  portable 
software  at  the  higher  level.  He  feels  that  more  thought  is 

required  as  to  the  function  of  operating  systems  and  the 

philosophy  behind  them,  rather  than  on  what  a  particular  machine 
or  a  particular  operating  system  does. 


DIJKSTRA62  CR6,649 

Dijkstra,  E.W.;  Some  Meditations  on  Advanced  Programming; 
Proceedings  of  IFIP  Congress  1962  (1962)  pp. 535-538. 

In  this  paper  Dijkstra  reflects  on  several  topics.  He  reviews  the 
bad  architecture  of  past  machines  and  of  the  then  largely 
available  commercially-produced  machines.  He  points  out  that 
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since  programming  is  equivalent  to  machine  design,  programmers 
should  accept  the  responsibility  of  influencing  future  designs  by 
exploring  them  in  software.  ALGOL  60  is  mentioned  as  an  entity 
which  provoked  considerable  effort  in  translator  writing  and 
considerable  thought  about  programming  languages.  Puzzle-minded 
programming  is  criticized  in  favor  of  a  systematic  approach. 
Correctness,  reliability  and  their  demonstration  are  emphasized. 
Dijkstra  concludes  with  a  desire  to  see  a  symbiotic  craft sman-and- 
his-tools  relationship  develop. 


DIJKSTRA65a  CR9,006 
Dijkstra,  E.W.;  Programming  Considered  as  a  Human  Activity; 
Proceedings  of  IFIP  Congress  (1965)  pp. 213-217. 

The  main  thrust  of  this  paper  is  that  the  programmer  and  his  mind 
are  an  important  part  of  the  computing  process.  The  use  of  these 
parts  of  the  process  is  not  necessarily  optimized  by  making  poorer 
use  of  the  machine.  Rather  there  can  be  a  gain  in  efficiency  of 
usage  of  the  machine  by  using  top-down,  GOTO-less  program 
structuring  which  is  more  easily  created  and  understood  by  humans. 

The  paper  suggests  that  investigation  be  done  to  see  to  what 
degree  the  goals  of  humans  and  the  characteristics  of  the  machine 
are  parallel,  and  that  we  do  not  flatly  assume  that  these  are 
opposites . 

The  author  asserts  that  elegance  leads  to  desirable  features  of 
programming  languages.  As  the  title  implies,  he  approaches 
programming  through  the  basic  pattern  of  human  understanding.  From 
this  attitude  he  criticizes  programming  to  date  and  describes  more 
natural  and  elegant  structures. 

Dijkstra  gives  a  clear  statement  of  successive  refinement  of  a 
problem,  emphasizing  (1)  division  into  parts,  (2)  the  parts 
together  form  the  whole,  and  (3)  the  principle  of  non¬ 
interference.  Here  also  are  his  classic  arguments  for  program 
correctness  and  against  the  "GO-TO."  He  proposes  four  desirable 
language  features  and  concludes  that  an  area  for  work  is  that  of 
the  compromises  of  efficency  against  convenience. 


DI JKSTRA6  5b  CR9,023 
Dijkstra,  E.W.;  Solution  of  a  Problem  in  Concurrent  Programming 
Control;  CACM  8,  9  (1965)  pp.569. 

This  paper  presents  an  algorithm  which  ensures  that  at  any  moment 
one  and  only  one  of  a  number  of  mainly  independent  sequential 
cyclic  processes  with  restricted  means  of  communications  with  each 
other  is  engaged  in  the  "critical  section"  of  its  cycle. 


DI JKSTRA68a 

Dijkstra,  E.W.;  Go  To  Statement  Considered  Harmful;  CACM  11,3 
(March  1968)  pp. 147-148. 
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The  concept  of  independent  co-ordinates  with  which  to  describe  the 
progress  of  a  process  is  discussed.  Such  co-ordinates  cannot  be 
found  if  unstructured  control  transfers  are  allowed  in  programming 
languages.  Suggestions  are  made  for  alternative  constructions 
that  are  both  flexible  and  structured  so  that  an  independent  co¬ 
ordinate  system  can  be  maintained. 


DIJKSTRA68b  CR14.979 
Dijkstra,  E.W.;  The  Structure  of  the  "THE"  Multiprogramming 
System;  CACM  11#5  (May  1968)  pp. 341-346. 

The  design  of  the  T.H.E.  Multiprogramming  system  is  discussed  with 
an  emphasis  on  methodology.  The  basic  unit  in  this  system  is  a 
process  and  these  are  organized  on  hierarchical  levels  which  serve 
tc  implement  independent  abstractions.  Program  correctness  and 
verification  are  briefly  discussed  and  a  short  appendix  gives  some 
explanation  of  semaphores  and  some  results  on  prevention  of 
deadlock. 


DIJKSTRA68C 

Dijkstra,  E.W.;  Co-operating  Sequential  Processes;  In  Genuys,  F. 
(ed.  )  ,  Programming  Languages.  Academic  Press  (1968)  pp. 43-112. 

The  use  of  semaphores  in  mutual  exclusion  and  process 
synchronization  is  discussed.  Techniques  for  implementing  co¬ 
operation  among  parallel  processes  are  examined  in  detail.  A  proof 
of  correctness  is  presented  for  the  message  interpreter  for  the 
T.H.E.  System.  Finally,  the  Bankers  Algorithm  is  discussed  as  a 
means  of  preventing  deadlock. 


DIJK  STRA6  8d  CR16.717 

Dijkstra.  E.W.;  A  Constructive  Approach  to  the  Problem  of  Program 
Correctness;  BIT  8,  3  (1968)  pp. 174-186. 

Dijkstra  states  that  there  are  two  ways  to  establish  the 
correctness  of  a  program.  As  an  alternative  to  a  posteriori 
techniques  this  paper  proposes  that  a  priori  correct  programs  can 
be  produced  by  controlling  the  process  of  program  generation  in  a 
manner  that  is  demonstrated  on  a  simple  problem. 


DIJKSTRA71a 

Dijkstra,  E.W.;  Concern  For  Correctness  as  a  Guiding  Principle  for 
Program  Composition;  in  Hugo,  J.S.  (ed) ,  The  Fourth  Generation, 
Infotech  Ltd.,  Berkshire,  England  (1971)  pp. 357-367. 

In  this  state-of-the-art  report,  Dijkstra  reviews  the  current 
state  in  the  programming  world,  and  notes  the  unfortunate 
situation  with  respect  to  programming  and  debugging  practices.  As 
an  alternative  to  this,  he  proposes  and  presents  a  strong  argument 
for  a  structural  approach  to  the  construction  of  "intellectually 
manageable"  programs  which  yields  correctness  proofs  with  much 
less  effort. 


-96- 


Older  Articles 


DIJKSTRA7 1b 

Dijkstra,  E.W.;  A  Short  Introduction  to  the  Art  of  Programming; 
Eindhoven  University,  EWD316  (August  1971)  pp.1-97. 


EVANS  70 

Evans,  D.J.  (ed.);  So ftware70 ;  Transcripta  Books  (1970)  pp. 1-197. 

This  book  is  the  report  of  a  conference  aimed  at  consolidating 
what  was  known  about  software.  Various  important  academic  and 
industrial  topics  were  highlighted.  The  following  papers  are 
included : 

Evans,  D.J.;  The  current  software  situation 

McMonigall,  J.P. ;  Criteria  for  the  design  and  implementation 
of  application  packages  for  third-generation  computers 


FELDMAN68  CR14,729 
Feldman,  J.,  and  Gries,  D.;  Translator  Writing  Systems;  CACM  11,2 
(February  1968)  pp, 77-113. 

A  survey  of  the  state-of-the-art  in  translator  writing  systems  up 
to  1968.  It  is  a  useful  discussion  of  the  automation  of  writing 
translators  for  programming  languages  and  includes  a  formal  study 
of  syntax. 


FI0YD67 

Floyd,  R.W.;  Assigning  Meanings  to  Programs;  Proceedings  of  a 
Symposium  in  Applied  Mathematics,  American  Mathematical  Society 
(1967)  pp. 19-32. 

Described  is  a  system  of  associating  propositions  in  a  first  order 
predicate  calculus  with  each  '’arrow"  in  a  program  flowchart.  The 
propositions  are  used,  along  with  some  axioms  presented  in  the 
paper,  to  prove  statements  about  the  properties  of  commands  in  a 
program.  The  author  deals  specifically  with  proving  claims  about 
the  ranges  of  variables  in  a  program.  Such  a  proof  could  then  be 
used  in  a  proof  of  program  correctness.  Also  dealt  with  is  a 
technique  of  proving  program  termination. 

This,  in  combination  with  a  paper  by  Burstall  [ BURSTALL72  ] , 
provides  a  strong  algebraic  system  for  proofs  of  programs.  It  is 
clear,  however,  that  the  author's  technique  is  rather  tedious  and 
may  not  be  of  great  value  in  proofs  of  large  programs. 


GAINES69 

Gaines,  R.S.;  The  Debugging  of  Computer  Programs;  Ph.D.  Thesis, 
Princeton  University,  Department  of  Electrical  Engineering  (1969) 
pp. 1- 169. 

This  thesis  is  a  general  study  of  tools  and  techniques  for 
debugging  programs,  and  the  design  of  compilers  and  operating 
systems  to  facilitate  debugging.  It  includes  an  analysis  of  the 
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programming  process  to  identify  carefully  what  the  problems  are  in 
debugging  and  how  they  arise.  Based  on  this  analysis,  the 
fundamental  notions  that  underlie  most  debugging  aids  are 
identified.  The  facilities  that  are  currently  available  to 
programmers  using  batch  operating  systems  are  discussed,  and  a 
number  of  new  ones  are  presented. 


GOOD70  CR2 

Good,  D.I.;  Toward  a  Man-Machine  System  for  Proving  Pr 
Correctness;  Ph.D.  Thesis,  University  of  Wisconsin,  Departme 
Computer  Science  (1970). 


The  problem  considered  is  the  realization 
program-proving  system  that  is  applicable 
programs.  The  inputs  to  the  system  are 
specifications  this  program  must  meet  in  order 
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GFIES71 

Gries,  D. ;  Compiler  Construct  ion  for  Digital  Computers ;  Wiley, 
N.Y.  (1971)  pp. 1-493. 


GRISHMAN70  CR19,806 
Grishman,  R.;  The  Debugging  System  "AIDS";  Proc.  SJCC  36  (1970) 
pp. 59-64 . 


HATFIELD71  CR23,271 
Hatfield,  D.,  and  Gerald,  J. ;  Program  Restructuring  for  Virtual 
Memory;  IBM  Systems  Journal  10,3  (1971)  pp.  168-192. 


Much  effort  has  been  directed  of  late  to  the  improvement  of 
problem-program  performance  on  virtual  memory  systems.  This  paper 
describes  a  procedure  for  determining  the  memory-use 
characteristics  of  a  program  and  then,  through  a  combination  of 
automatic  and  manual  algorithms  and  heuristics,  rearranging  the 
code  to  improve  paging  behavior.  The  method  described,  as  opposed 
to  many,  is  practical,  in-use,  and  results  in  a  (typically)  5  to  1 
i  irpr  oveme  n  t . 
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HOARE69  CR18,328 

Hoarer  C.A.R.;  An  Axiomatic  Basis  f cr  Computer  Programming;  CACM 
12,10  (October  1969)  pp. 576-580. 

Working  with  a  simple  set  of  operations  on  data  (integer  addition, 
subtraction,  and  multiplication),  Hoare  examines  various  axioms 
which  may  be  added  to  the  axioms  of  arithmetic  to  cover 
peculiarities  of  computer  operations,  using  overflow  as  an 
example.  He  then  introduces  an  axiom  to  deal  with  the  assignment 
operation,  and  two  rules  of  inference.  Using  these  axioms  and 
inference  rules,  he  investigates  formal  statements  which  can  be 
made  about  sequential  operations  and  iteration,  and  gives  an 
example  of  the  application  of  the  rules  to  a  simple  program. 
(Regrettably,  no  rule  is  proposed  for  a  conditional  statement, 
which  would  complete  a  minimal  set  of  control  constructs.)  The 
paper  concludes  with  a  consideration  of  the  limitations  of  the 
study,  particularly  the  lack  of  a  basis  for  proof  of  program 
termination,  and  some  cogent  arguments  for  the  desirability  of 
using  formal  techniques  for  language  design  and  proofs  of  program 
correctness. 


HCARE71a  CR2  3, 647 

Hoare,  C.A.R.;  Procedures  and  Parameters:  An  Axiomatic  Approach; 
Symposium  on  Semantics  o£  Algorithmic  Languages,  Springer  Verlag, 
Berlin  (1971)  pp. 102-116. 

The  author  develops  a  formalism  which  facilitates  proofs  of 
program  correctness.  He  needs  to  impose  a  restriction  on 
procedure  calls,  which  is,  however,  a  desirable  programming 
feature. 


HO AR  E71b  CR2  2, 29  6 
Hoare,  C.A.R.;  Proof  of  a  Program:  FXND;  CACM  14,1  (January  1971) 
pp. 39-45. 

An  important  non-trivial  example  of  cqi current  program 
construction  and  proof  of  correctness.  Hoare  mentions  some 
disadvantages  and  weaknesses  to  this  approach,  but  he  obviously 
feels  that  such  formal  proofs  are  extremely  important  and  that 
eventually  computer  assistance  may  be  possible. 


KING7 1 

King,  J.C.;  Proving  Programs  to  be  Correct;  IEEE  Transactions  on 
Computers  C-20,11  (November  1971)  pp. 1 33 1- 1 336. 


KNUTH71a 

Knuth,  D.E.,  and  Floyd,  R.E.;  Notes  on  Avoiding  "go  to" 
Statements;  Information  Processing  Letters  1,1  (February  1971) 
pp. 23-31 . 

This  paper  discusses  the  use  of  the  "goto"  statement  and  methods 
of  avoiding  them.  The  "goto"  statement  can  be  replaced  by  a 
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procedure  call,  or  a  program  segment  containing  a  "goto"  can  be 
imitated  by  using  an  iterative  loop.  The  methods  are  applied  to 
two  typical  programming  examples:  symbol  table  searching  and 
backtracking.  The  article  discusses  when  certain  methods  are 
desirable  and  when  they  would  only  add  ambiguity  to  the  program. 


KNUTH71b  CF2  2, 30  0 

Knuth,  D.E.;  An  Empirical  Study  of  FORTRAN  Programs;  Software 
Practice  and  Experience  1,2  (April/June  1971)  pp.  105-133. 


This  paper  deals  with  a  study  of  a  sample  of  programs  written  in 
FORTRAN  by  a  wide  variety  of  people  for  a  wide  variety  of 
applications.  Statistical  results  of  the  study  are  presented  in 
the  paper,  together  with  some  of  their  apparent  implications  for 
future  work  in  compiler  design.  The  principal  conclusion  which 
may  be  drawn  is  the  importance  of  a  table  of  freguency  counts 
which  record  how  often  each  statement  is  performed  in  a  typical 
run.  With  the  table  of  frequency  counts,  a  programmer  or  an 
optimizing  compiler  may  optimize  a  program  by  merely  optimizing 
those  portions  of  the  program  which  are  executed  most  frequently, 
and  thus  reduce  the  amount  of  time  spent  in  producing  efficient 
programs . 


LC  NDO  N70a 

London,  R.L.;  Bibliography  on  Proving  the  Correctness  of 
Programs;  in  Meltzer,  B. ,  and  Michie,  D.  (ed.). 
Intelligence  5,  American  Elsevir  Publishing  Company,  Inc. 
pp.  569-580.'’ 
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.L.;  Bibliography  on  Proving  the 
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pp. 1-8. 
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Examples ; 


L.;  Proving  Programs  are  Correct: 
BIT  10,  2  (1970)  pp. 168-182. 


CR2 1 ,040 
Some  Techniques  and 


LONDON71 

London,  R.L.;  Experience  with  Inductive  Assertions 
Programs  Correct;  In  Engler,  E.  (ed)  ;  Symposium  on 
Algorithmic  Languages;  Springer-Verlag,  Berlin  (1971) 
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MADNICK70 

Madnick,  S.E.;  Design  Strategies  for  File  Systems;  M.I.T.,  Project 
MAC,TR-78  (October  1970)  pp.  1-106. 

This  report  exemplifies  the  idea  of  "top-down"  or  "levels  of 
abstraction"  analysis  as  applied  to  the  design  of  file  systems. 
The  two  basic  concepts  imposed  on  the  analysis  are  that  files 
should  (except  for  the  top-most  user-oriented  level)  be  subject  to 
a  uniform  representation,  and  that  the  tasks  of  naming,  storing 
and  retrieving  information  should  be  analyzed  into  a  hierarchy  of 
activities  ranging  from  the  purely  logical  to  the  purely  physical. 

A  file  is  viewed  as  a  named,  sequentially  organized  (virtual) 
memory.  That  is,  the  items  of  information  in  the  file  are 
considered  to  be  assigned  to  sequential  "addresses."  The  fact  that 
the  items  are  (say)  related  by  a  tree  structure  is  of  no  interest 
except  in  the  top-most  user-oriented  level  of  the  system. 


MANNA69  CR17,722 
Manna,  Z.;  The  Correctness  of  Programs;  Journal  of  Computer  and 
System  Sciences  3,2  (May  1969)  pp. 119-127. 

This  paper  presents  formal  predicate  calculus  results  on  the 
correctness  and  equivalence  of  programs  in  terms  of  the 
satisfiability  (or  unsatisf iability)  of  certain  first-order 
formulas.  The  only  programs  considered  are  those  with  assignment 
statements  and  conditional  jumps.  Correctness  of  programs  depends 
on  their  termination  and  final  result,  as  does  the  equivalence  of 
programs.  Theorems  are  presented  concisely  and  rigorously  along 
with  short  illustrative  examples. 


MANNA71  CR2  3,686 

Manna,  Z.,  and  Waldinger,  R.J.;  Toward  Automatic  Program 
Synthesis;  CACM  14,3  (March  1971)  pp. 151-165. 


MCFARLAND70  CR21,223 
McFarland,  C. ;  A  Language-oriented  Computer  Design;  Proceedings  of 
the  FJCC  37  (1970)  pp. 629-640. 

Difficulties  in  using  computers  are  often  the  result  of  poor 
system  design  or  a  mismatch  between  the  language  and  the  computer 
being  used.  It  is  the  responsibility  of  the  user  to  produce  a  good 
algorithm  for  solving  his  problems,  but  he  is  entitled  to  assume 
that  good  construction  in  a  higher  level  language  will  produce 
efficient  object  programs.  To  achieve  this  it  is  proposed  that 
hardware,  operating  systems,  and  primary  languages  all  be  designed 
together.  The  article  gives  an  example  of  a  language  (TPL)  and  a 
computer  system  (Hydra)  designed  in  this  manner. 


M  CKEEM AN  6  6  CR13,436 

McKeeman,  W.M;  An  Approach  to  Computer  Language  Design;  Stanford 
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University,  Department  of  Computer  Science,  Technical  Report  CS48 
(August  1966)  pp. 1-124. 


The  major  responsibility  of 
user.  In  order  to  reduce  the 
might  undertake,  implement 
language  which  contains  the 
task  s. 


language  design  should  rest  with  the 
compiler  writing  task  to  one  a  user 
an  extendable  compiler  for  a  kernel 
concepts  common  to  all  computing 


MCKEE  MAN67  CR14,136 
HcKeeman,  W.M.;  Language  Directed  Computer  Design;  Proceedings  of 
the  FJCC  31  (1967)  pp. 413-417. 


An  entertaining  article  which  begins  by  imagining  what  would 
happen  if  we  had  to  compile  on  a  computer  modelled  after  a  Turing 
machine  rather  than  on  one  modelled  after  a  desk  calculator.  The 
author  complains  that  compilers  and  operating  systems  are  getting 
less  reliable  and  more  expensive  to  produce.  Among  the  remedies 
suggested  are:  1)  making  hardware  designers  write  a  compiler;  2) 
not  designing  machines  with  multiple  arithmetic  formats  and  the 
attendent  conversion  problems;  3)  replacing  the  ability  to  address 
any  word  in  the  machine  with  lexic-level  addressing;  and  4) 
building  common  needs  (e.g.,  a  scanner)  into  the  hardware. 


"The  obvious  attack  for  programmers  and  hardware  people  together 
is  to  devise  a  language  which  reflects  what  we  want  to  do  and  how 
to  do  it  (for  instance,  in  parallel)  and  machine  structures 
effective  in  handling  that  language." 


MCKEE  MAN70 

McKeeman,  W.M.,  Horning,  J.J. 
Generator ;  Prentice-Hall,  N.J. 


and  Wortman,  D.B. ; 
(1970)  pp.  1-527. 


CE2  1,021 
A  Compiler 


This  book  teaches  the  theory  and  practice  of  compiler 
construction.  A  System/360  realization  of  the  tools  is  presented 
and  documented.  The  theory  section  gives  examples  of  translating 
expressions,  declarations,  and  control  structures,  emphasizing  the 
relationships  between  recognizing  and  attaching  meaning  to  program 
parts.  Theoretical  groundwork  is  laid  for  studying  formal 
solutions  to  the  recognition  process  (parsing) .  This  leads  into 
the  discussion  of  automatically  generating  parsers  using 
precedence  and  LR  (k)  techniques. 


The  practice  section  describes 
components  of  the  translator  writin 
(the  XPL  compiler),  ANALYZER  (the 
(the  proto-compiler)  are  discussed 
compilers  and  examples  of  conce 
section.  Finally,  the  interface  to 
appendices. 


both  the  language  XPL  and  the 
g  system.  The  components  XCOM 
parser  generator) ,  and  SKELETON 
both  as  tools  for  building 
pts  described  in  the  theory 
OS/360  is  described  in  the 


-102- 


Older  Articles 


MILLS  70  CRl 9,422 

Mills,  H.D.;  Syntax  Directed  Documentation  for  PL360;  CACM  13,4 
(April  1970)  pp. 216-222. 

Mills  has  developed  an  interactive  system  that  parses  a  PL360 
program,  paragraphs  it,  and  interactively  interrogates  the 
programmer  about  the  intention  of  each  main  syntactic  construct. 
This  attempts  to  ensure  that  every  source  line  is  well  documented. 
The  programmer’s  responses  are  kept  in  an  online  program 
management  system.  This  system  can  subsequently  be  asked  about 
identifier  usage  and  the  purpose  of  certain  classes  of  actions. 
Primitive  text  retrieval  from  the  documentation  given  a  keyword 
may  also  be  done.  This  system  is  essentially  experimental. 
However  it  does  point  the  way  to  future  automated  documentation 
systems. 


MILLS71 

Mills,  H.D.;  Chief  Programmer  Teams:  Principles  and  Procedures; 
IBM  Federal  Systems  Division,  no.  FSC71-5108  (June  1971)  pp. 1-27. 

This  paper  describes  the  basic  functional  characteristics  of  the 
chief  programmer  team  method  of  project  management,  and  the 
principles  which  underlie  the  method.  The  objective  is  to  achieve 
a  practical  synthesis  of  several  contemporary  theories  of  good 
programming  practice.  The  concept  of  top-down  design  is  reflected 
in  the  hierarchical  structure  of  the  team.  Structured  control 
constructs  are  used  to  obtain  program  underst andability  and 
verifiability.  A  form  of  "egoless  programming,"  in  the  form  of  a 
"programming  production  library,"  is  introduced  "to  move 
programming  from  private  art  to  public  practice."  Unfortunately, 
nc  concrete  evidence  is  given  to  support  the  practicality  of  the 
approach. 


NAUR63  CR  4 , 54  0 
Naur,  P. ;  Revised  Report  on  the  Algorithmic  Language  ALGOL60 ;  CACM 
6,1  (1963)  pp . 1-17. 

"The  report  gives  a  complete  defining  description  of  the 
international  algorithmic  language  ALGOL  60.  This  is  a  language 
suitable  for  expressing  a  large  class  of  numerical  processes  in  a 
form  sufficiently  concise  for  direct  automatic  translation  into 
the  language  of  programmed  automatic  computers"  (from  the  first 
paragraph) . 

This  is  a  classic  paper  of  computer  science.  It  introduces  the 
language  that  is  the  father  of  almost  all  later  languages.  It 
does  so  concisely  and  clearly.  "Of  particular  interest  are  its 
introduction  of  all  the  main  program  structuring  constructs,  the 
simplicity  and  clarity  of  its  description,  rarely  egualled  and 
never  surpassed"  (HOARE73a ) . 
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N  AUR6  9a  CR 1 9, 4  20 

Naur,  P.;  Programming  by  Action  Clusters;  BIT  9,  3  (1969)  pp. 

25Q-258. 


NAUR  6  9b 

Naur,  P.,  and  Randell,  B.  (ed.);  Software  Engineering;  NATO 
Scientific  Affairs  Division,  Brussels,  Belgium  (1969)  pp. 1-231. 

This  report  contains  summaries  of  discussions,  and  working  papers 
presented  at  a  Working  Conference  on  Software  Engineering.  Topics 
covered  are  the  design,  production,  distribution,  and  service  of 
software,  and  the  relation  of  software  to  hardware.  The  following 
papers  are  included: 

Berner,  R.W.;  Checklist  for  Planning  Software  System  Production 
Dijkstra,  E.W.;  Complexity  Controlled  by  Hierarchical  Ordering 
of  Function  and  Variability 

Gill,  S.;  Thoughts  on  the  Seguence  of  Writing  Software 
Mcllroy,  M.D.  ;  Hass  Produced  Software  Components 
Pinkerton,  T.B.;  Performance  Monitoring  and  Systems  Evaluation 
Randell,  E. T. ;  Towards  a  Methodology  of  Computing  System 
Design 

Selig,  F. ;  Documentation  Standards 


NEUMANN69  CR19,622 
Neumann,  P.G.;  The  Role  of  Motherhood  on  the  Pop  Art  of  Systems 
Programming;  Proceedings  Second  ACM  Symposium  on  Operating  Systems 
Principles  (October  1969)  pp. 13-18. 

The  author  seeks  to  identify  the  reasons  why,  in  spite  of  what 
Mother  has  told  us,  we  continue  to  pay  no  more  than  lip-service  to 
the  principles  of  good  system  design  and  implementation.  Everyone 
agrees  that  clarity  and  efficiency  are  important,  but  nobody  does 
anything  about  realizing  them.  Several  interesting  paragraphs  on 
the  use  of  higher-level  languages  are  included. 


NIEVERGELT70  CR20,659 
Nievergelt,  J.,  and  Irland,  M.I.;  Bounce-and-Skip :  a  Technique  for 
Directing  the  Flow  of  Control  in  Programs;  The  Computer  Journal 
13,3  (August  1970)  pp. 261-262. 

The  bounce-and-skip  technique  for  directing  the  flow  of  control  in 
block  structured  programs  was  developed  as  a  result  of  the  search 
for  alternatives  to  the  *go  to'  statement  which  was  questioned  by 
Dijkstra  in  1968  as  a  desirable  feature  of  high-level  programming 
languages.  This  method  is  regarded  by  the  authors  as  an  efficient 
way  to  implement  all  of  the  common  control  statements  of  high- 
level  languages  as  well  as  a  tool  for  program  debugging. 

Bounce-and-skip  provides  the  user  with  two  options:  To  delay  the 
use  of  the  result  of  a  test  indefinitely,  or  to  make  the  entry  and 
exit  of  BEGIN_END  blocks  conditional  upon  the  last  test  performed. 
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Each  test  performed  is  coded  as  either  neutral  (its  result  has 
already  been  used) ,  successful  or  unsuccessful.  This  indicator  is 
matched  to  a  list  of  permissible  settings  of  the  indicator 
associated  with  each  BEGIN  and  END.  Under  a  mismatch  condition 
control  is  prohibited  from  entering  through  a  given  BEGIN  and  thus 
it  sk ips  the  block,  or  control  is  not  allowed  to  exit  through  a 
given  END  and  hence  it  bounces  and  positions  itself  just  after  the 
corresponding  BEGIN. 


ORGASS69  CR1 8,260 
Orgass,  R.J.,  and  Waite,  W.M.;  A  Base  for  a  Mobile  Programming 
System;  CACM  12,  9  (September  1969)  pp. 507-510. 


PARNAS67  CR1 4,055 
Parnas,  D.L.,  and  Darringer,  J.A.;  SODAS  and  a  Methodology  for 
System  Design;  Proceedings  of  the  FJCC  31  (1967)  pp. 449-474. 

SODAS  is  the  first  of  a  number  of  systems  which  attempt  to  combine 
simulation  with  design  and  implementation  in  an  effort  to  increase 
system  production  efficiency.  SODAS  allows  the  modules  of  the 
"object  system"  to  be  specified  at  any  desired  level  of  detail  and 
in  a  number  of  different  languages,  and  provides  several 
advantages:  all  interfaces  are  completely  specified;  the 
"fracturing"  of  the  system  into  its  various  modules  is  shown  to  be 
correct  or  incorrect  prior  to  implementation;  and  it  is  possible 
to  determine  at  the  outset  if  low-level  inefficiencies  imposed  by 
high-level  design  decisions  will  significantly  impact  the 
performance  of  the  resulting  system.  Parnas' s  system  has  several 
drawbacks  (compared  to,  say,  R.M.  Graham's  D.E.S.):  primarily  the 
use  of  several  different  languages  is  confusing,  particularly 
since  the  implementation  language  is  distinct  from  the  simulation 
language (s) . 


PARNAS71 

Parnas,  D.I.;  A  Paradigm  for  Software  Module  Specification  with 
Examples;  Carnegie-Mellon  University,  Department  of  Computer 
Science  (March  1971)  pp.1-19. 


POOLE  6 9  CR 1 9, 6 1 2 
Poole,  P.C.,  and  Waite,  W.M. ;  Machine-Independent  Software; 
Proceedings  of  ACM  Second  Symposium  on  Operating  Systems 
Principles  (October  1969)  pp. 19-24. 

The  authors  advocate  that  machine  independence  be  achieved  through 
the  use  of  macros  rather  than  compilers,  with  the  following 
principal  advantages:  1)  the  abstract  machine  may  be  flexibly 
extended:  there's  no  need  to  design  a  "complete"  language  at  the 
outset;  and  2)  optimization  may  be  tailored  to  specific  needs, 
through  modification  of  the  appropriate  macros. 
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R ANDELL7 1 

Randell,  B.;  Highly  Reliable  Computing  Systems;  University  of 
Newcastle  upon  Tyne,  Technical  Report  20  (1971)  pp. 1-39. 

This  report  discusses  the  needs  for  and  the  problems  of  achieving 
high  reliability  from  complex  computing  systems.  System 
performance  and  system  reliability  are  both  commodities  for  which 
the  user  has  to  pay.  Usually,  they  are  inversely  related  (e.g.  , 
high  system  reliability  usually  means  a  loss  in  system 
performance).  Operating  systems  are  intended  to  extend  the 
reliability  of  and  cope  with  the  unreliability  of  the  hardware. 
However,  it  may  turn  out  that  the  operating  system  presents  a 
bigger  reliability  problem  than  the  hardware.  In  a  computing 
system,  it  should  be  the  responsibility  of  the  hardware  to  detect 
hardware  errors  and  the  responsibility  of  the  operating  system  to 
cope  with  and  isolate  these  errors. 

The  user  should  have  a  measure  of  the  reliability  of  his  system. 
The  correctness  of  software,  and  thus  its  reliability,  is  relative 
to  some  criteria.  These  criteria  should  be  part  of  the  detailed 
specifications  and  design  of  the  system.  Nevertheless,  computing 
systems  should  have  provisions  for  coping  with  software  bugs, 
similar  tc  hardware  error  handling  facilities,  since  the  absence 
of  bugs  cannot  be  guaranteed.  Thus,  a  reliable  system  should  have 
effective  means  for  coping  with  and  isolating  both  hardware  and 
software  errors  and  should  be  capable  of  continuing,  if  possible, 
even  though  errors  have  occurred. 

In  conclusion  Randell  states  that  "the  most  vital  task  to  be 
undertaken  in  designing  a  computing  system  for  a  highly  critical 
and  complex  environment  is  that  of  attempting  to  minimize  the 
extent  to  which  reliance  is  put  on  the  correct  and  continuing 
functioning  of  the  system." 


RICHARDS69  CR18,258 

Richards,  M.;  BCPL:  A  Tool  for  Compiler  and  System  Writing; 
Proceedings  of  the  SJCC  34  (1969)  pp. 557-566. 

BCPL  is  a  simplification  of  CPL  (Basic  CPL)  developed  as  a  tool 
for  writing  relatively  machine  independent  systems  programs, 
especially  compilers.  The  most  important  characteristic  of  the 
language  is  its  simple  semantic  structure  built  around  "an 
idealized  object  machine"  which  makes  BCPL  reasonably  machine 
independent  and  easy  to  define  accurately.  The  language  is 
typeless  (the  only  data  object  being  a  bit  string  of 
implementation-defined  length)  and  has  a  wealth  of  constructs  to 
control  flow  in  an  orderly  fashion.  The  article  gives  an 
interesting  discussion  of  the  advantages  of  typeless  languages  and 
has  some  general  comments  on  design  of  languages  for  system 
im piemen tat ion. 


R0BERTS67  CR17,857 

Roberts,  K.V.;  The  Readability  of  Computer  Programs;  Computer 
Bulletin  10,4  (March  1967)  pp.  17-24. 


-106- 


Older  Articles 


RCSS67  CR2  0,013 
Ross,  D.T.;  The  AED  Approach  to  Generalized  Computer  aided  Design; 
Proceedings  of  the  ACM  22nd  National  Conference  (1967)  pp. 367-385. 


ROSS70 

Ross,  D.T.;  Uniform 
Software  Engineering 
Press,  New  York  (1970) 


CR2 1 ,883 

Referents:  An  Essential  Property  for  a 

Language;  Software  Engineering  1,  Academic 

pp. 91-101. 


RUSTIN71 
Rustin,  R. 
Hall,  N.J. 


CR2  2,801 

(ed . ) ;  Debugging  Techniques  in  Large  Systems;  Prentice- 

0971)  pp. 1-141. 


This  book  is  concerned  with  the  "control  and  extermination"  of 
"bugs"  in  highly  complex  programming  systems.  Some  topics  covered 
are:  procedures  to  guarantee  programs  to  be  free  of  bugs,  style 
that  avoids  or  isolates  bugs,  strongly  disciplined  testing 
techniques,  and  specific  methods  for  particular  environments.  The 
following  papers  are  included: 


Blair,  J.;  Extendable  Non-Interactive  Debugging 
Grishman,  R. ;  Criteria  for  a  Debugging  Language 
King,  J.;  A  Verifying  Compiler 

Kulsrud,  H. E. ;  Extending  the  Interactive  Debugging  System 
Helper 

Mills,  H.  ;  Top  Down  Programming  in  Large  Systems 
Schwartz,  J.;  An  Overview  of  Bugs 
Supnik,  R. M. ;  Debugging  Under  Simulation 


SAMMET71 

Sammet,  J.E.;  A  Brief  Survey  of  Languages  Used  in  Systems 
Implementation;  SIGPLAN  Notices  6,9  (October  1971)  pp.1-19. 

A  good,  concise  survey  which  touches  upon  the  following  topics: 
managerial  and  technical  reasons  for  deciding  to  program  in  a 
high-level  language;  some  of  the  obvious  drawbacks  to  high-level 
languages;  a  list  of  "motherhood"  criteria  for  desirable 
programming  language  characteristics;  brief  and  not-t oo-usef ul 
descriptions  of:  ALGOL,  BLISS,  FORTRAN,  IMP,  LRLTRAN,  NELIAC, 
Pascal,  and  PL/I.  Recommended,  and  it's  short. 


SC0WEN71 

Scowen,  R.S.,  Allin,  D.,  Hillman,  A.D.,  and  Shimell,  M.;  SOAP  -  A 
Program  which  Documents  and  Edits  ALGOL60  Programs;  Computer 
Journal  14,2  (1971)  pp. 133-135. 

This  paper  discusses  SOAP,  a  paragrapher  for  ALGOL60  programs. 
The  program  is  a  sort  of  parser,  doing  some  syntax  checking.  The 
program  allows  the  option  of  replacing  any  token  terminal  wherever 
it  occurs  with  another  terminal.  The  documentation  referred  to, 
however,  is  cnly  a  cross-reference  listing,  with  some  nice 
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features.  The  paragrapher,  then,  does  not  really  do  any 
documentation,  but  merely  produces  bookkeeping  listings. 


STEEL67  CR13.919 
Steel,  T.B.;  Standards  for  Computers  and  Information  Processing; 
in  Alt,  F.L.,  and  Rub  in off,  M.  (ed.).  Advances  in  Computers  8 
(1967)  pp.  103-152. 

With  such  diversity  in  the  field  of  Computer  Science,  some  form  of 
unification  must  be  taken.  Standardization  of  the  terminology, 
problem  definition,  programming  languages,  communication 
characteristics  and  physical  (i.e.,  nonelectrical)  characteristics 
of  computers  and  information  processing  devices,  equipment  and 
systems  is  a  must. 

"The  present  chaos  in  programming  languages  is  so  bad  that  it  is 
cften  compared  to  the  Tower  of  Babel,  and  any  help  is  worth 
having."  The  complexity  in  attempting  to  standardize  programming 
languages  -  an  almost  imposible  task  -  is  recognized.  The 
developments  and  accomplishments  in  the  universal  standardization 
of  the  languages,  Algol,  Fortran  and  Cobol,  are  related. 

Although  only  twelve  standards  were  produced  in  the  six  years  of 
work,  the  process  should  accelerate  rapidly  if  the  author's 
surmise  is  correct.  One  should  see  real  and  useful  progress 
toward  the  creation  of  systematic  standards  to  replace  the  chaotic 
organization  now  prevalent,  particularly  in  the  programming 
languages  area. 


TCU71 

Tou,  J.T.  (ed.);  Software  Engineering.  Vol  Academic  Press  (1971) . 

A  collection  of  papers  presented  at  a  symposium  in  1969.  The 
first  volume  covers  computer  organization,  systems  programming, 
and  programming  languages;  the  second  volume  covers  information 
retrieval,  pattern  processing,  and  computer  networks.  The 
following  papers  are  included: 

Barton,  R.S.;  Ideas  for  Computer  Systems  Organization:  A 
Personal  Survey 

Berner,  R.W.;  Manageable  Software  Engineering 

Maurer,  W.  ;  Generalized  Interpretation  and  Compilation 


TURSKI70 

Turski,  W.  (ed.);  The  Efficient  Production  of  Large  Programs; 
Polish  Academy  of  Sciences  (1970)  pp. 1-130. 

WAITE 70  CR1 9,61 0 

Waite,  W.M.;  Euilding  a  Mobile  Programming  System;  The  Computer 
Journal  13,1  (February  1970)  pp. 28-31. 


-108- 


Older  Articles 


The  author  discusses  a  technique  which  he  believes  to  be 
fundamental  to  the  improvement  of  mobility  of  programming  systems. 
It  is  recognized  that  the  mobility  of  a  programming  system  and  the 
associated  application  programs  is  an  extremely  important  aspect 
whenever  a  user  upgrades  or  changes  his  equipment.  The  mobility 
of  systems  software  is  a  function  of  the  number  of  installations 
which  are  involved  and  in  general,  the  mobility  of  a  program  is 
completely  dependent  on  the  mobility  of  the  programming  system  it 
utili zes. 

The  technigue  for  providing  mobility  is  based  on  the  concept  of  an 
abstract  machine:  a  hypothetical  computer  ideal  for  a  particular 
task.  The  program  for  this  task  is  written  for  the  abstract 
machine  and  to  run  such  a  program  on  a  real  machine,  the  abstract 
machine  must  first  be  realized  in  some  way. 

The  author  concludes  the  article  by  discussing  both  the  advantages 
and  disadvantages  of  the  technique  of  abstract  machine  modelling 
and  points  out  that  the  system  has  proved  extremely  mobile  in 
practice,  having  been  implemented  in  less  than  one  man-week  on 
nine  different  occasions. 


W  EIDER  MA  N7 1 

Weiderman,  N.H.;  Synchronization  and  Simulation  in  Operating 
System  Construction;  Ph.D.  Thesis,  Cornell  University,  Department 
of  Computer  Science  (September  1971). 

Description  of  an  operating  system  design  methodology  which 
proceeds  in  a  strict  top-down  order  and  combines  simulation  with 
implementation  to  verify  system  structure  and  predict  object- 
system  performance.  a,  good  review  of  other  techniques  is 
included;  chapters  three  and  four  are  of  particular  interest.  For 
comparison  purposes,  see  Graham’s  D.E.S.,  Parnas's  SODAS  and  the 
Zurcher  and  Randell  paper. 


WEINBERG71  CR23,001 
Weinberg,  G.M.;  The  Psychology  of  Computer  Programming;  Van 
Nostrand  (1971)  pp. 1-288. 

This  book  is  unique  in  that  it  discusses  the  art  and  science  of 
computer  programming  not  from  the  viewpoint  of  the  machines  and 
programs  which  are  generally  thought  of  as  its  main  subject 
matter,  but  from  the  human  factors  viewpoint.  The  author  discusses 
the  factors  in  a  programmer’s  psychological  makeup  which  affect 
his  programs,  and  the  ways  in  which  programs  vary  according  to  the 
personality  and  emotional  outlook  of  their  creators.  Programming 
team  environments  are  looked  at  from  the  point  of  view  of  the 
individual  programmer.  The  effect  of  both  his  formal  and  informal 
connections  within  (and  without)  the  team  on  his  productivity  and 
programming  style  is  considered. 

Suggestions  are  made  for  improvements  in  the  fields  of  programming 
lcnguage  design,  education  of  programmers,  programming  aptitude 
tests,  project  structure,  and  many  others  based  on  empirical 
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psychological  data  and  studies  of  human  beings  and  their 
characteristics. 

The  author  expresses  some  of  the  spirit  of  the  book  in  his 
concluding  remarks,  when  he  expresses  the  hope  that  the  knowledge 
of  human  factors  involved  in  the  programming  task  and  systems  in 
general  presented  in  the  book  will  be  of  use  to  the  reader  in  his 
own  office,  project,  class,  or  other  programming  environment. 


WIRTH68  CR1 4,506 
Wirth,  N.;  PL360,  A  Programming  Language  for  the  360  Computers; 
J  ACM  15,  1  (January  1968)  pp. 37-74. 


W IRTH7 1  a  CR2 1,63  0 
Wirth,  N. ;  Program  Development  by  Stepwise  Refinement;  CACM  14,4 
(April  1971)  pp. 221-227. 

Programming  is  usually  taught  by  examples.  Unfortunately  these  do 
not  usually  demonstrate  widely  applicable  techniques,  rather  they 
show  what  a  computer  can  do.  Wirth  proposes  a  better  method  of 
teaching,  that  cf  stepwise  refinement. 

Stepwise  refinement  is  intended  to  demonstrate  the  gradual 
development  of  a  program.  As  an  example,  Wirth  takes  the  eight 
queens  problem  and  applies  the  method.  First  the  problem  is 
stated  in  very  general  terms,  leaving  many  details  unspecified. 
The  problem  is  gradually  refined  by  filling  in  details  at  each 
succeeding  step.  At  each  step  a  choice  is  made  as  to  the  best 
design  and  solution  for  that  level.  This  process  continues  until 
the  solution  is  expressible  in  a  programming  language. 

Wirth  concludes  that  this  method  successfully  splits  the  problem 
into  a  number  of  subtasks  at  each  step.  The  degree  of  modularity 
obtained  determines  the  ease  or  difficulty  of  the  problem.  This 
method  allows  one  to  express  the  problem  in  notation  that  is 
natural  to  the  problem,  until  the  notation  of  the  problem  becomes 
that  of  the  programming  language.  Each  step  requires  concise 
design  decisions  which  affect  the  final  solution. 


WIRTH7 1 b  CR2  6,925 
Wirth,  N.;  The  Programming  Language  Pascal;  Acta  Informatica  1 
(1975)  pp. 35-63. 

This  paper  describes  the  programming  language  Pascal  and  provides 
a  justification  for  its  creation.  Wirth  intended  the  language  as 
a  teaching  vehicle  and  as  a  tool  for  the  creation  of  large 
programs.  He  tried  to  keep  the  language  small,  systematic,  and 
efficient.  Pascal  introduced  several  novel  concepts  and  has 
inspired  several  other  languages  (see  [  CLARK7 1  ]) . 

In  style,  this  paper  is  like  the  Algol  60  report  but  unfortunately 
it  is  neither  as  clear  nor  as  complete.  See  [ HABERMANN73 ]  for 
harsh  but  partially  justified  criticism. 
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CR2  3,196 
Practice 


WIRTH  7 1c 

Wirth,  N. ;  The  Design  of  a  PASCAL  Compiler;  Software 
and  Experience  1,4  (October/December  1971)  pp. 309-333. 


WOLFE69 

Wolfe,  J.M.;  Testing  for  Programming  Aptitude;  Datamation  15,4 
(April  1969)  pp. 67-72. 


WULF7  1 

Wulf,  W. A  .  ,  Russell,  D.E 
for  Systems  Programming* 


CR23  ,01 1 

and  Babermann,  A.  N. ;  BLISS;  A  Language 
r»CM  14,  12  (December  1971)  pp. 780-790. 


YCUNGS70 

Youngs,  E.A.  ;  Error-Proneness  In  Programming;  Ph.D.  Thesis, 
University  of  North  Carolina  at  Chapel  Hill,  Department  of 
Psychology  (1970)  pp. 1-147. 

This  thesis  basically  describes  a  programming  experiment  to  study 
human  programming  errors  with  an  eye  towards  suggesting 
improvements  in  programming  languages  and  processors.  Although  no 
startling  facts  were  made  nor  strong  conclusions  reached,  this 
thesis  begins  to  develop  techniques  and  concepts  for  quantifying 
program  development.  The  thesis  is  rather  easy  to  read,  and  it  is 
interesting  to  see  how  he  codes  and  evaluates  data  on  programming 
e  rror s. 
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